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A ,tech.net magazin Brainstorm" a Dupla KV rovathoz 
hasonló, ám a személyes kérdésfelvetést és vitát is le- 
hetővé tevő rendezvény, melynek célja: 


e az elsőre talán ismeretlen technológiák 
élő bemutatása 

s a cikkekhez kapcsolódó kódok 
megírása/kipróbálása 

s a terjedelmi okokból kimaradt 
információk átadása 


E magazinnal együtt a rendezvényre érvényes belépő- 


jegyet minden előfizetőnkhöz eljuttattuk. 
További információk a belépőjegyen olvashatók. 


Várjuk Önöket a 
NetAcademia Mesterkurzusokon 
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(Bár belépőjegyet adtunk, ez a tény önmagában nem biztosítja helyét a rendezvényen. A jegy célja előfizetőink elsődlegességének biztosítása, de a korlátozott résztve- 


vői létszám (100 fő) miatt a regisztráció kötelező. Jelentkezzen, amíg nem késő!) 
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Ha valaki elolvassa az MCP vagy MCSE címek 
viselésének feltételeit, találkozhat egy olyan 
kikötéssel, mely szerint nem szabad rossz hí- 
rét kelteni a Microsoft szoftvereinek, szakmai 
fórumokon pedig azok előnyeit kell ismertetni. 
Jártamban-keltemben elég sok kollégával ta- 
lálkozom, akik - nyíltan vagy burkoltan - becs- 
mérlik a Microsoft rendszereit, különösen a 
rendelkezésre állásukat tartják nagyon rossz- 
nak. Mivel a névjegykártyámon nem virít sem- 
milyen cím, szívesen elbeszélgetek velük inkognitóban, s 
igyekszem tárgyi tévedéseiket helyreigazítani. Egy-egy dis- 
kurzus során kiderül, hogy gyakran még a legelemibb intéz- 
kedéseket sem teszik meg annak érdekében, hogy a rendsze- 
rük csak egy kicsit is tovább üzemeljen, a finomságokról szó 
sem esik. Valahogy szélmalomharcnak tűnik az egész. 
Elhatároztam tehát, hogy összegyűjtöm, és közkinccsé teszem 
azokat az információkat, amelyek segítségével hibatűrő Micro- 
soft rendszereket lehet létrehozni. Nem is biztos, hogy az ope- 
rációs rendszernél kell ezt kezdeni. Ma egy átlagos rendszer- 
gazda talán tisztában van egy PC felépítésével, de már egy be- 
lépő szintű szerver is titkokat rejt a számára, a négy- és nyolc- 
processzoros Góliátokhoz , ingyen hozzácsapott" csodákról már 
ne is beszéljünk. S ha valaki nincs tisztában a lehetőségeivel, 
akkor egy beruházási döntés előtt nem lesz képes , súgni" a 
döntéshozónak, hogy mit is kellene belecsempészni még abba 
a gépbe, hogy esetleg ne kelljen éjjel egyig küszködni majd, 
ha beüt a krach. Mert persze a felhasználó ideje szent, ami 
rendjén is van. Olyanok vagyunk mi, mint Münchausen báró: 
vagy kirántjuk saját magunkat az összeomlások mocsarából, 
vagy csak magunkra vethetünk, ha nem tesszük. 

Az, hogy korábban nem volt minden rendjén, nemcsak a felhasz- 
nálók látták, hanem a Microsoft is. Ha belegondolunk, akkor a 
Windows NT megszületésének egyik mozgatórugója is a nagyobb 
megbízhatóság, végső soron a nagyobb rendelkezésre állás volt. 
A Windows 2000 azonban minden elődjén túltett, hogy stabil és 
megbízható eszköz legyen. Többfrontos támadás volt ez a hibák 
ellen, igen sok fegyvert felvonultatva. A leghatásosabbnak tűnő 
ezek közül a fürtszolgáltatás, amely a Windows NT 4.0 Enterprise 
Editionben debütált, s most a Windows 2000 izmosabb változa- 
taiban nyílt ki igazán. Nem tudok róla, hogy lenne még egy 
ilyen hardverfüggetlen, operációs rendszerbe épített és olcsó 
megoldás a magasabb rendelkezésre állás biztosítására. 

Sok mindenre mondják, hogy ,ez a jövő". Én merem állítani, 
hogy a nagyobb rendelkezésre állás tényleg a jövő, és 
legalább két okom van ezt feltételezni. Egyrészt a kapitaliz- 
mus nálunk is ,begyűrűzik", a tulajdonosok facsarják a me- 
nedzsmentet, ők pedig tűzzel-vassal keresik majd a profitot és 
üldözik a profit kiesését. Ha hozzávesszük ehhez, hogy na- 
gyon közel van az idő (ha el nem jött máris) amikor a számí- 
tógépre bízzuk legalábbis mindennapi jövedelmünket, akkor 
nem kétséges, hogy nem áll meg a talpán az a rendszergaz- 
da, aki hanyagsága, nemtudása vagy hozzá nem értése miatt 
akiejti" a cégét az üzletből pusztán azzal, hogy nem gondos- 
kodott időben a rendszere megbízhatóságáról. 
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Mostan színes 


kockákról álmodom... 


A másik ok a leendő IT vezetők becsülete. A jó vezető tudja, 
hogy bár ő nem ért a bitekhez és a bájtokhoz, egy leállás 
mégis az ő lelkén szárad, mert - ahogy a közmondás tartja - 
a fejétől bűzlik a hal. Ez pedig becsületbeli ügy. Egy IT veze- 
tő a messiás, aki hirdeti az új világ igéjét: használjátok az in- 
formatikát, mert az jövedelmez. De vajon mit ér annak a sza- 
va, akinek a munkatársai nem képesek életben tartani az új 
világnak a rájuk bízott szeletét? 

Eléggé nyomós, a fizetésünket és munkahelyünket érintő ér- 
vek ezek számunka, a technikai szakemberek számára, hogy 
komolyan vegyük a dolgunkat, és hibatűrő, lehetőleg agyon- 
csaphatatlan szolgáltatásokat hozzunk létre. Komoly munka 
komoly felkészülést kíván. Azt ajánlom a kedves Olvasónak, 
hogy kövesse folyamatosan a fürtszolgáltatásról szóló cikkso- 
rozatot. Ha van már olyan eszközük, amely képes e kompo- 
nens futtatására, akkor sok hasznos, a mindennapi üzemelte- 
téssel kapcsolatos tudnivalót találhatnak majd bennük. Ha 
pedig még nincs ilyen rendszerük, akkor ötlettárként lehet 
használni a cikkeket, hogy a következő beruházáskor lendíte- 
ni lehessen azon a becsületen. 

Júliusban a barcelonai TechEd konferencián beszélgetés köz- 
ben azt mondta az egyik kollégám, hogy egy cluster a ,négy- 
kilences" rendelkezésre állás biztosítására való. 99.9990 üzem- 
időre pedig még kevés alkalmazásnak van szüksége, ezért a 
clusternek még nem jött el az ideje. Erre azt válaszoltam, 
hogy nálunk a szervereinknek jobb rendelkezésre állása van, 
mint a WAN vonalainknak, mégsem elégedett a főnököm. S 
közben azon gondolkodtam, hogy egészen más dolog beszél- 
ni akár öt kilencesről, mint megcsinálni azt. 

Hadd osszak meg egy titkot a kedves Olvasóval. Még egy clus- 
ter birtokában sem fog tudni senki egyik pillanatról a másik- 
ra 99.9990-os rendelkezésre állást produkálni, mert ennek a 
tudása nem (csak) a szoftverben rejlik. Ilyen precizitáshoz a 
teljes üzemeltetés módszertanának és szemléletének kell 
átalakulnia. Nem lehetetlen, csak nem megy rögtön. A Micro- 
softnak van egy módszertana, amelyet Microsoft Operation 
Frameworknek neveznek és épp azt a célt szolgálja, hogy 
kihozza azt a lehetőséget a szoftverrendszerekből, amely e- 
gyébként bennük szunnyad. Ennek elsajátítása és alkalmazá- 
sa azonban olyan rossz beidegződések elhagyását igényli, 
amelyeket nem lehet csettintésre végrehajtani. 

A cikksorozat csak abban segít, hogy az első három-négy ki- 
lencest elérjük - micsoda változás már ez is. Ezután könnyebb 
lesz majd a továbblépés. 

Kosztolányi Dezső versének címét kissé elferdítve én most 
azokról a színes kockákról álmodom, amelyek a nagy üzembiz- 
tonságot reklámozták. Jó volna, ha néhányuk stabil építőkő- 
vé válhatna a mi rendszereinkben. 


Lepenye Tamás (MCSE) 
lepenyetomal.hu 


tech.net! 


Farkasokkal 
táncoló 
(I. rész) 


Wolfpack annyit tesz: farkasfalka. Wolfpack volt a kódneve 
annak a szoftvernek, amelyet a Microsoft 1997-ben adott 
ki, és a világ clusterserverként ismert meg. Az a szándék, 
hogy minél nagyobb rendelkezésre állást lehessen biztosí- 
tani a Windows NT alapú rendszereknek, ebben a szolgálta- 
tásban kristályosodott ki leginkább. Magyarországon még a 
Windows megbízhatatlanságának van híre, pedig már sok 
éve másról szól a fáma. Ezzel a cikksorozattal a Windows 
2000 Advanced Server cluster (magyarul kiszolgálófürt) szol- 
gáltatását szeretném egy kicsit alaposabban bemutatni. Mi- 
vel gyakorló rendszermérnök vagyok, szeretném feltárni az 
olvasó előtt azokat a motivációkat, amelyek a megvásárlás 
mellett szólhatnak, a műszaki környezetet, amelyet a szoft- 
ver igényel, és mindenekelőtt a tapasztalatot, amelyet az 
elmúlt hónapokban megszereztem. Találónak érzem az egy- 
kori kódnevet: a clusterek nagy, erős és összetett rendsze- 
rek, amelyekhez fontos az alapos felkészültség. De aki bá- 
tor, az akár a farkasokkal is táncol. 


Mi a szerverfürt? 

A szerverfürt egy vagy több olyan kiszolgáló, amelyek meg- 
felelő hardvereszközök megléte esetén együttműködnek, 
hogy a rendszergazdák által definiált szolgáltatásokat a le- 
hető legkisebb kieséssel működtessék. Első pillantásra fur- 
csának tűnhet az ,egy" a meghatározásban, de majd látha- 
tó, hogy ennek is van értelme. Hogy a továbbiakban a fo- 
galmi rendszer egyértelmű legyen, meg kell határoznunk 
néhány, a későbbiekben gyakran előforduló kifejezést. 

Az állomás (node): Ha a cluster azt az együttest jelenti, 
amely a szolgáltatásokat folyamatosan biztosítja, akkor az ál- 
lomás a cluster egyik gépe. A Windows NT Server 4.0 Enterprise 
Edition és a Windows 2000 Advanced Server cluster maximáli- 
san két állomásból állhat. A Windows 2000 Datacenter Server 
segítségével 4 node-ból álló cluster is építhető. 

A fürtszolgáltatás (cluster service): Egy szabványos NT szer- 
viz, amely mindkét állomáson fut, feladata pedig a rábízott erő- 
források biztosítása az ügyfelek felé. A szolgáltatás egy megfe- 
lelő jogosultságú tartományi fiók kontextusában működik. 

Az erőforrás (resource): Egy olyan hardver, szoftver vagy 
logikai komponens, amely működéséért a clusterszolgál- 
tatás felel. Erőforrás lehet egy lemez, egy NetBIOS gépnév, 
egy szolgáltatás (service) vagy akár egy IP cím is. 

Ouorum disk: Az erőforrások között van egy különleges, a 
guorum disk. Ez egy olyan lemez, amely a két állomás kö- 
zös ,tudását" tartalmazza (egy adatbázis formájában) a 
cluster konfigurációjáról és állapotáról. 

Függőség (dependency): Az erőforrások nem elszigetelt egy- 
ségek, hanem egymással kapcsolatban állnak, függnek egymás- 
tól. Például egy adatbáziskezelőnek szüksége van az adatbázis 
fájljaira és tranzakciós állományaira ahhoz, hogy elindulhas- 
son. Ezek azonban egy lemezen találhatók. Az adatbáziskezelő 
szolgáltatás erőforrás tehát függ egy lemezerőforrástól. 
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WINDOowSs 2000 





A csoport (group): A logikailag együtt kezelt erőforrások 
csoportot alkotnak. A fürtszolgáltatás általában erőforrás- 
csoportokat és nem egyedi erőforrásokat kezel. A csoporto- 
kat a rendszergazdák alakítják ki úgy, hogy minden erőfor- 
rást tartalmazzanak, amely egy alkalmazás üzemeltetéséhez 
szükséges. Egy SOL Serverhez szükséges például egy gépnév, 
egy IP cím, egy lemez, és az MSSOLServer erőforrás. 
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5 SOL Server a fürtben 


Átköltözés (failover): Ha egy állomás nem képes működ- 
tetni egy adott erőforráscsoportot, akkor a fürtszolgáltatás 
átköltözteti az egészet a másik állomásra. Az átállás tényét 
a guorum disken található fürtadatbázisban rögzíti. 
Visszaköltözés (failback): Ha már mindkét állomás képes 
üzemeltetni az erőforráscsoportot, akkor a cluster a vissza- 
költöztetési szabályok alapján helyreállítja az eredeti 
feladatmegosztást. A szabályokról a későbbiekben szó lesz. 
Virtuális kiszolgáló (Virtual server): Az erőforráscsoportok 
beállíthatók úgy, hogy a felhasználók számára mint valóságos 
kiszolgálógépek jelenjenek meg. Ehhez az szükséges, hogy le- 
gyen név- és IP cím erőforrásuk. Azok a csoportok, amelyek ren- 
delkeznek ilyen erőforrásokkal, virtuális kiszolgálók is egyben. 
Szívhang (Heartbeat): Az állomások folyamatosan figyelik 
egymás állapotát, pontosabban azt, hogy képesek-e reagál- 
ni kérésekre. Ezt a forgalmat nevezzük szívhangnak. 

A cluster Microsoft-féle implementációja az ún. ,shared- 
nothing", vagyis a ,semmi közös" elven épült. Ez azt jelen- 
ti, hogy a cluster által definiált erőforrások egy adott pilla- 
natban csak az egyik szerverhez tartoznak, a másik nem fér- 
het hozzájuk. Hiba esetén fordul a kocka, és a másik állomás 
válik az erőforrások birtokosává. Közös erőforrások, amelyek 
fölött egyszerre gyakorolnának felügyeletet a node-ok, nin- 
csenek, - vagyis semmi sem közös. Ez az elv azonban nem 
tévesztendő össze azzal a ténnyel, hogy léteznie kell olyan 
(merevlemez) eszköznek, amelyeket mindkét állomásnak el 
kell érnie. Ez az eszköz legtöbbször egy merevlemez-alrend- 
szer, amely fizikailag közös. Tehát egy kiépített cluster ren- 
delkezik egy fizikai szinten mindkét állomás számára elérhe- 
tő lemezrendszerrel, amelyben az egyes lemezek vagy az 
egyik, vagy a másik node-hoz tartoznak egy időpillanatban. 
Még néhány általános tudnivaló. A clusterszolgáltatás leg- 
inkább kapcsolatorientált szoftverek rendelkezésre állásá- 
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WINDOws 2000 FARKASOKKAL TÁNCOLÓ 
nak növelésére való. Ilyen például az SOL Server vagy az 
Exchange. Ezt a szabályt azonban nem kell kőbe vésettnek 
tekinteni, mert a DHCP, WINS, sőt még az IIS is fürtözhető. 
A kapcsolatmentes technológiák (Például IIS) rendelkezés- 
re állásának növelésére mégis inkább más módszerek hasz- 
nálatosak, elsősorban a Network Load Balancing Server, 
mert NLBS-sel akár 32 állomást magában foglaló fürt is 
építhető. Vannak továbbá olyan szolgáltatások, amelyek ál- 
landó elérhetőségére az elosztott architektúrák a megfele- 
lőek. Ilyen az Active Directory vagy a DNS. 

A clusterszolgáltatás a Windows 2000 Advanced Server és a 
Windows 2000 Datacenter Server része. A Windows 2000 
Server nem tartalmazza ezt a komponenst. Az Advanced 
Server ára jóval magasabb, mint az egyszerű Windows 2000 
Serveré (kb. háromszorosa) , alaposan mérlegelni kell tehát a 
váltást. Windows NT 4.0 Serverről Windows 2000 Advanced 
Serverre frissíteni a szoftvert alig valamivel kevesebb, mint 
egy teljesen új licencet vásárolni, Windows NT 4.0 
Enterprise Editionről viszont az átállás jóval barátságosabb. 
A magasabb árért cserébe az Advanced Server elsősorban a 
rendelkezésre állást növelő szolgáltatásokban nyújt többet, 
s a cikksorozat végére kiderül, hogy bőven ,megéri az árát". 


Hogyan működik a fürt 

A szerverfürt közös tudása a guorum lemezen található, 
amelyet leginkább egy dedikált, vagyis csak erre a célra 
használt, merevlemezen elhelyezkedő tranzakciós adatbá- 
zisként lehet elképzelni. Ez a közös tudás definiálja a cso- 
portokat és bennük az erőforrásokat, valamint azt, hogy a 
csoportokat mely node-ok birtokolhatják. Ha valamilyen ok- 
nál fogva az egyik gép nem képes az általa birtokolt cso- 
portok számára a működést biztosítani, akkor a másik állo- 
más átveszi a csoportok működtetését. A felhasználók, akik 
ténylegesen a virtuális kiszolgálók szolgáltatásait veszik 
igénybe, nem észlelik a hibát, vagy csak rövid kiesést ta- 
pasztalnak. Ha ábrázolni kell a szereplőket, akkor leginkább 
egy ingaórához hasonló szerkezetet rajzolhatunk. 


Felhasználó 





Node1 Node2 

o A virtuális kiszolgálók ingázása 

Jogos a kérdés, hogy mi történik akkor, amikor az inga épp 
a két állomás között jár. Akkor is üzemel a szolgáltatás? Nem. 
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A cluster nem biztosítja a teljes, 10090-os rendelkezésre ál- 
lást, nem tükrözi a hálózati kapcsolatokat, és az ügyfélol- 
dali szoftver tulajdonságai határozzák meg, hogy a felhasz- 
náló észreveszi-e a kimaradást. Ha például kiszolgálóolda- 
lon egy Exchange szoftvert futtatunk egy fürtön, a ügyfél- 
oldalon pedig egy Outlook dolgozik, akkor az Outlook az 
inga" átbillenése után ott folytatja, ahol korábban abba- 
hagyta. Egy SOL Server kliens, főleg egy felette futó alkal- 
mazás (SAP, JDE stb.) viszont igényelheti az ügyfelek új- 
raindítását. Az inga átlendülése tehát kritikus tényező, sze- 
rencsére az állomások ezt nagyon gyorsan elvégzik. (Egy 
J.D Edwards B7.3.3.1 és egy SOL Server 2000 150 egyidejű 
felhasználó esetén 10 másodperc alatt vándorol át egyik fürt- 
tagról a másikra. Ez saját tapasztalat, de ettől lehetnek elté- 
rések, amelyet az erőforrások száma és természetesen a ki- 
szolgálók izmossága is befolyásol.) 

Szóval 10 másodperc kiesés. Sok? Hasonlítsuk ezt össze az- 
zal a leállással, amit egy nem cluster gép nyújt, amelyiknek 
meghibásodik a processzora. Mennyi ideig tart azt kicserél- 
ni, még ha van is alkatrész? Egy óra? És ha nincs alkatrész? 
Két nap? Két nap helyett 10 másodperc. Jó csere? De mond- 
hatok más példát is. Ha tervszerűen karbantartást kell vé- 
gezni, mikor és mennyi idő alatt történik ez meg? Egy éj- 
szaka alatt? Egy hétvégén? Mennyi ennek a költsége? Nem 
egyszerűbb nappal, munkaidőben dolgozni? A cluster ezt 
lehetővé teszi. Az erőforrások éjszaka átcsoportosíthatók az 
egyik állomásra, reggel pedig lehet karbantartani (ütni) a 
másikat. Erre ideális a szerverfürt. 


A cluster konfigurációja 

Tekintsük át, mire érdemes ügyelni egy clusterkörnyezet ter- 
vezésekor. A Microsoft azt javasolja, hogy egy cluster kevés 
számú, jól definiált szolgáltatást nyújtson, továbbá minden 
funkciót a fürtszolgáltatáson keresztül érjenek el a felhasz- 
nálók. Ezt én egyszerű és tiszta konfigurációnak nevezem. 
Egyszerű, mert kevés alkalmazást felügyel a cluster szerviz, 
és tiszta konfiguráció, mert nincs fürtön kívüli funkció. Az 
ajánlás mögött az az elgondolás húzódik meg, hogy ilyen 
rendszer üzemeltetése jóval kiszámíthatóbb és egyszerűbb, 
és várhatóan beváltja a hozzá fűzött magas rendelkezésre 
állás reményét. Egy apró szépséghibája van a fenti gondo- 
latnak: nagyon drága. Ha állandóan szeretnénk biztosítani a 
felhasználók számára a nyomtatás lehetőségét, a levelezést, 
a vállalatirányítási rendszert, a felhasználói könyvtárakat, a 
névfeloldást stb. stb. és mindig egy-egy új fürtbe kötött 
szerverpárt állítanánk be, igencsak megcsapolnánk a válla- 
latunk beruházásra fordítható pénzeszközeit. Ez nem járha- 
tó út. A hasznos azonban lehet viszonylag olcsó is, csupán 
annyit kell tenni, hogy a szolgáltatásokat egyetlen clusterre 
kell költöztetni. Ha egyetlen, jól megtervezett, erőforrások- 
kal ellátott kiszolgálópárra telepítünk mindent, akkor akár 
már a beruházási költségek is összevethetőek lesznek 5-6 
különálló kiszolgáló megvásárlásával. A rendelkezésre állás 
és az üzemeltetési költségek pedig össze nem hasonlítható 
módon jobbak lesznek, mivel az egyszer megvásárolt redun- 
dancia minden szolgáltatásra kiterjed, míg különálló gépek 
a tartalékok hiánya miatt nem képesek megbízhatóan kiszol- 
gálni a felhasználókat, legalábbis a fürthöz viszonyítva nem. 
Mindenképp ajánlatos tehát, hogy minél több szolgáltatást 
biztosítson egy fürt, mert a kiajánlott szolgáltatásokra jutó 
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fajlagos redundanciaköltség így alacsonyabb lesz. Igen, 
igen, ez a szerverkonszolidáció. Meggyőződésem, hogy 
nem is olyan sokára ez a nézet általánosan elterjedt lesz, 
és a Windows kiszolgálófürt nem csodabogár ritkaságként 
gubbaszt egy teremben, hanem általános és olcsó módja 
lesz a rendelkezésre állás növelésének. 

Nem tartozik a cikk keretei közé egy kiszolgáló méretezésé- 
nek elemzése, ezért processzorszámra és memóriaméretre 
nem tudok javaslatot tenni. Néhány szót azonban érdemes 
szentelni a közös lemezek kialakítására. A legegyszerűbb 
megoldás a közös SCSI busz alkalmazása. Kétségtelenül ol- 
csóbb megoldás, de nem számol a jövővel. A clustert nem 
egy évig használjuk majd és nem is kettőig. Olyan módszert 
érdemes alkalmazni, amely a technológiai életciklusa elején 
jár, így van esélye annak, hogy pár év múlva nem fogunk 
bővíthetőségi problémákkal küzdeni. Ma a tárolórendszerek 
terén a jövőbe mutató szabványok a Fibre Channel techno- 
lógia és a Storage Area Network. Nemcsak nagyobb sávszé- 
lességet nyújtanak, de rugalmasabb konfigurációt is lehe- 
tővé tesznek. Ha tehát ez lehetséges, javaslom a SAN- 
megoldások alkalmazását. A SAN szintén egyfajta konszoli- 
dáció, csak épp az adattárolás területén. Ez egy olyan adat- 
tároló hálózat, amelyben kiszolgálók, merevlemeztömbök 
és szalagos könyvtárak kapcsolódnak egymáshoz SAN háló- 
zati eszközökön keresztül, amelyeket (hogy az életet ne bo- 
nyolítsuk) éppúgy huboknak, switcheknek és routereknek 
hívunk, mint a hagyományos hálózati eszközöket és szere- 
pük a nevükhöz hasonlatos. A SAN belső titkait most nem 
részletezve annyit érdemes elmondani, hogy SAN hubot ak- 
kor érdemes használni, ha az (adat) hálózaton kommuniká- 
lók száma viszonylag kevés (pl. egy cluster és egy-két merev- 
lemez alrendszer) , a switch viszont alkalmasabb a két vagy 
több clustert magában foglaló rendszerekhez. Mellesleg a 
SAN rendszer egyik előnye, hogy elegendő egyetlen men- 
tést végző eszközt (pl. tape library-t, szalagos könyvtárat) 
vásárolni, az képes lesz a teljes adattároló hálózat lemen- 
tésére úgy, hogy a tényleges (pl. Ethernet) hálózatot nem 
terheli. A mentési eszköz ugyanúgy közös, mint a lemezal- 
rendszerek, tehát bármely gép használhatja. 

A kiszolgálókat egy SAN-hálózathoz ún. gazdaadapterekkel 
(host adapter) lehet kapcsolni. A nagyobb sebesség érdekében 
érdemes a 66MHz-es PCI buszokat használni erre a célra. Egy 
egyszerű fürt SAN rendszerrel az ábrán látható módon nézne ki. 






Datafrouter 


Tape Library 


5 Kiszolgálófürt SAN-nal 
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FARKASOKKAL TÁNCOLÓ (I. RÉSZ) 
Ez szép is, jó is, olcsó is, csak egy apró gondja van. 

A fürtszolgáltatást azért telepítjük, hogy hiba esetén a 
beépített és felkészített redundancia megakadályozza a 
szolgáltatás kiesését. Csakhogy a szépen felépített szoftver- 
redundanciánkat tönkretettük azzal, hogy egyetlen hubra 
bíztuk a teljes adathálózat kommunikációját. Ez bizony hi- 
ba. A tervezés során módszeresen irtani javallott a , single 
point of failure"-t, vagyis az egy pontból eredő megbízha- 
tatlanságot, költői fordításban az Achilles-sarkot. A teljes 
redundanciának persze megint csak ára van, de némi mérle- 
gelés után belátható, hogy ez már nem nagy tétel. Célszerű 
redundáns vezérlővel ellátni a lemezalrendszert is, be kell 
építeni egy további SAN hubot (vagy switchet). A , mindent 
a felhasználóért" konfiguráció valahogy így néz ki: 


Node2 


Node1 





Datafrouter 


Tape Library 


5 Redundáns SAN hálózattal Achilles ellen! 


Gyakorlati tapasztalatként annyit fűzök a fenti ábrához, 
hogy nem minden gyártó rendelkezik olyan SAN hubbal, 
amelyhez data router csatlakoztatható, ekkor viszont az ál- 
taluk kínált switch árfekvése némileg kedvezőbb a konku- 
renciáénál. Vásárlás előtt érdemes leülni a lehetséges szál- 
lítókkal, és alaposan végigtárgyalni az igényeket. Meggon- 
dolandó továbbá, hogy a data router vajon mindkét hubhoz 
csatlakozzon-e. Amúgy is csak egy van belőle, ráadásul 
csak" a mentést biztosítja, vagyis a rendelkezésre állásá- 
val szembeni követelmények - tartalék eszközről lévén szó 
- mindenképp alacsonyabbak, mint a kiszolgálók esetén. 

A lemezalrendszer kontrollere képes hardveres redundancia 
létrehozására (RAID 1, RAID5, RAID 0--1), melyre nagy szük- 
ség van, a cluster ugyanis nem kezeli a szoftveres merevle- 
meztömböket. Hogy ez miért van így, arról még értekezünk. 
Látható, hogy a kiszolgálófürtök beszerzése nem a ,Józsi- 
most-van-akció-vegyetek-egy-szervert" alapon történik. 
Alaposság, megfontoltság, tervezés - ezek a fő feltételei 
annak, hogy az ember nekiugorjon a farkasfalkának. Leg- 
közelebb meg is tesszük. 


Lepenye Tamás (MCSE) 
lepenyet 2omal.hu 
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Mi az, hogy névfeloldás, és hogy működik? Miért van rá 
egyáltalán szükségünk? Milyen sorrendben történik a név- 
feloldás, és miért? Miért kell ezt nekem ismernem? Nagyjá- 
ból ezekre a kérdésekre kaphatjuk meg a választ a cikket vé- 
gigolvasva. Gondolom most sokan hátradőlnek és azt 
mondják: ja kérem, ezt én mind tudom, nincs erre szüksé- 
gem. Ennek ellenére mindenkinek azt tudom csak tanácsol- 
ni, hogy tessék elolvasni, az ismétlés sosem árt; illetve sze- 
retnék a Windows 2000-rel kapcsolatban néhány hasznos 
built-in segédeszközt ajánlani. Kezdjünk is bele! 


Miért kell erről beszélnünk? 

A magyarázat, csakúgy mint a folyamat, igen egyszerű. A szá- 
mítógépek kommunikációjuk során egy előre kiválasztott pro- 
tokollon keresztül kommunikálnak egymással (cikkem során 
csak a TCP/IP névfeloldásával foglalkozom). Tehát amikor 
gépemen megpróbálom megnézni a www.microsoft.com cí- 
met, akkor a kapcsolat ideje alatt az én gépem látszólago- 
san a www.microsoft.com címmel folytat adatátvitelt, valójában 
pedig a www.microsoft.com címhez tartozó TCP/IP címmel veszi 
fel a kapcsolatot. A folyamatot, melynek során egy gép egy má- 
sik számítógép (gyakorlatilag bármely hálózatra kapcsolt, kommu- 
nikálni képes eszközre igaz) nevéhez tartozó IP címet keresi, név- 
feloldásnak nevezzük. A névfeloldás folyamata igen összetett és 
elég sok lépésből áll. Pontosan az összetettsége miatt szükséges 
megismerkednünk vele (továbbá a Windows 2000 AD alappillére- 
ként emlegetett DNS kiszolgáló adatbázisában történő keresési fo- 
lyamat is a névfeloldás egy fajtája). Megtudtuk, hogy miért fontos 
a névfeloldás ismerete, most nézzük konkrétan a névfeloldást! 


Konkrétumok 

Napjainkban a legtöbb számítógépet háromféleképpen le- 
het elérni: 

"8 NetBIOS név alapján 

"8 FODN (fully gualified domain name) segítségével 

8 IP cím szerint 

Mind a három módszerhez más-más szolgáltatás használatára 
van szükségünk. Kezdetben zavaró lehet, hogy a Windows 
2000 nem tisztán használja a három névfeloldási módszert, 
hanem - nekünk akar segíteni a jámbor - ha az egyik nem 
megy, áttér a másikra. Ezzel óriási galibát is tud okozni, mert 
ha valaki nem tudja, hogy hibás DNS-sel is lehet pingelni (csak 
sokkal lassabb a névfeloldás) és bedöglött WINS-sel is lehet tá- 
voli megosztott könyvtárakra csatlakozni, jókat fog éjszakáz- 
ni. Íme néhány szolgáltatás névfeloldási preferenciája: 











Szolgáltatás Elsődleges Ha baj van... 
ua d Ü Et 

PING DNS NetBIOS 

net use " Wgeptshare NetBIOS DNS 

Active Directory DNS ... baj van 

Outlook DNS NetBIOS 
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Ez a táblázat csak tájékoztató jellegű, majdnem minden 
átállítható. Az Active Directory az egyetlen következetes 
jószág: ha nincs DNS, megkukul. 

De induljunk el és nézzük meg mind hármat (kettőt. Az IP-znév 
feloldás most kimarad)! 


NetBIOS név és a hozzá tartozó névfeloldási rendszer 
Az 1980-as években a Microsoft és az IBM közösen fejlesz- 
tette ki a NetBIOS névteret, a Windows9x és a Windows NT 
alap névfeloldásként mind a mai napig a NetBIOS haszná- 
latát támogatja. A NetBIOS egy 16 karakterből álló név, 
amit tetszésünk szerint megválaszthatunk. Természetesen 
törekednünk kell az egyediségre, továbbá a beszédes nevek 
használata megkönnyíti a hálózaton törtenő kommuniká- 
ciót. Érdemes egy hálózat tervezésekor annak névkonve- 
cióját is megtervezni. Azt mondtuk, hogy 16 karakter 
hosszú lehet egy NetBIOS név, ami igaz is, de a gyakorlat- 
ban ebből csak 15 karakter használható. A tizenhatodik egy 
speciális karakter, aminek a szerepe az, hogy a névhez tar- 
tozó számítógépen futó szolgáltatásokat a hálózaton egyér- 
telműen elérhetővé tegye. A 16. karakter a felhasználókhoz 
GUI (graphic user interface) szinten nem jut el (így emiatt 
valójában egy NetBIOS név legfeljebb 15 karakter lehet!) Te- 
hát a NetBIOS név fontos, mert egyedi, egy géphez csak 
egy tartozhat, és egy hálózatban két azonos NetBIOS nevű 
gép nem működhet. De hogy lesz ebből névfeloldás? 
Minden számítógép, melynek van NetBIOS neve, induláskor 
azt megpróbálja érvényesíteni, regisztrálni. Ilyenkor el- 
lenőrzi, hogy a hálózaton valaki használja-e már az általa 
preferált NetBIOS nevet. Amennyiben a név szabad, azt hi- 
telesíti, regisztrálja a nevet és a hozzá tartozó szolgáltatá- 
sokat. A másik lehetőség, hogy már valaki használja azt a 
nevet. Mi történik ilyenkor? A válaszhoz közelebb kerülünk, 
ha megnézzük, mi történik akkor, amikor senki sem hasz- 
nálja a nevet: a név és a gép szolgáltatásai regisztrálódnak. 
Ütközéskor a gép nem tudja majd hitelesíteni a nevet és a 
hozzá tartozó szolgáltatásokat. Számítógépünk hibát fog 
jelezni, hogy már létezik egy azonos nevű számítógép a há- 
lózaton, de ettől függetlenül elindul. Mi lesz a távolabbi 
következménye ennek? Mivel nem tudta regisztrálni a gép- 
nevet, ezért a NetBIOS kommunikációról le kell mondanunk 
és a NetBIOS-hoz kapcsolódó szolgáltatások sem indulnak 
el. A probléma könnyedén áthidalható, gépünknek egysze- 
rűen csak más nevet kell adnunk, majd újraindítjuk és már 
kész is. Amennyiben sikerült gépünknek olyan nevet adni, 
ami egyedi a hálózaton, gépünk a NetBIOS nevét érvénye- 
síti és a 16. karakter alapján a tallózó (magyarul: Browse :-) 
- a szerk.) szolgáltatás segítségével a hálózaton a szolgál- 
tatásait hirdeti, regisztrálja. Mik lehetnek ezek a szolgálta- 
tások? Ilyen például a Messenger, melynek segítségével a 
bejelentkezett felhasználónak rövid üzenetet küldhetünk. 
(net send username üzenet) De ilyen még a Server és a 


tech.net 


Workstation szolgáltatás is (nem összekeverendő a Windows 
NT 4.0 különböző termékeivel, ezek szolgáltatások). Tehát 
alapértelmezésben: akinek van NetBIOS neve, az hirdeti ma- 
gát és szolgáltatásait a hálózaton. Amikor egy számítógép- 
pel a hálózaton keresztül szeretnénk kommunikálni, először 
meg kell tudnunk a névhez tartozó TCP/IP címet, vagy a 
címhez tartozó nevet. Ilyenkor a gépünk egy olyan kérdést 
küld a hálózaton keresztül, amit a hálózat minden tagja 
megkap (Broadcast). Ha szeretnénk lefordítani emberi nyelv- 
re ezt az üzenetet, akkor valahogy így hangzik: Szóljon ne- 
kem az a számítógép, és küldje el az IP címet, akinek a 
neve srv01. (Ilyenkor az srvO1-hez tartozó IP címet keres- 
sük.) A hálózatunk, vagyis alhálózatunk minden számítógé- 
pe megkapja a kérdésünket, és valamennyi értelmezi is. 
Nyilván egy kivételével mindegyik eldobta a kérdést (vagy 
lehet, hogy senki nem válaszol), mert nem ők az srv01l 
NetBIOS név tulajdonosai. Igen egyszerűnek tűnik, de gon- 
dolkodjunk egy kicsit! Egy 172.31.0.0 255.255.0.0 hálózat 
esetén az alhálózatunkban akár több, mint 240 db számító- 
gép lehet (sőt, több!), mindenki megkapja kérdésünket és 
abból csak egy számítógép válaszára várunk. (Az olyan jelle- 
gű csomagokat, amit egy egész alhálózat minden tagja meg- 
kap, Broadcast üzenetnek hívjuk. Természetesen akár több al- 
hálózatra is átjuthat, ez csak a hálózati útválasztók (router) 
konfigurációjától függ.) Beláthatjuk, hogy ez felesleges for- 
galmat generál a hálózaton, amit könnyedén csökkenteni le- 
het. A hálózati útválasztók legáltalánosabb konfigurációjuk 
alapján az ilyen üzeneteket nem továbbítják, mert ezek kön- 
nyen a hálózat teljes terhelését eredményezhetnék és tenné 
mindezt úgy, hogy nem is hasznos forgalomról van szó, vagy 
ha hasznos, akkor is csak igen kis százaléka. 

Foglaljuk össze az eddigieket egy kicsit: minden gép ren- 
delkezhet NetBIOS névvel. A NetBIOS névhez tartoznak 
szolgáltatások, és mind a NetBIOS név, mind a névhez tar- 
tozó szolgáltatások listáját a tulajdonos gép regisztrálja és 
hirdeti. Amennyiben egy NetBIOS névvel szeretnék kom- 
munikálni a hálózaton, szükséges ismernem a NetBIOS 
névhez tartozó TCP/IP címet. Amikor ezt a hálózaton sze- 
retném megtalálni, egy Broadcast típusú üzenetet küld el 
a számítógépem, amiről megtudtuk, hogy ugyan biztosra 
megy, de felesleges üzenetekkel telítődik a hálózat a hasz- 
nálata esetén. Kell lenni valami más megoldásnak is, mint 
a Broadcast, és van is. Mi a legnagyobb probléma jelenleg? 
Nincs a hálózaton olyan kitüntetett funkciójú gép, amely 
egy listát vezetne a NetBIOS nevekről és a hozzájuk tarto- 
zó szolgáltatásokról; nincs olyan gép, akinek címezhet- 
nénk a kérdésünket. Rögtön rá is találtunk a megoldásra. 
Egy olyan gépre van szükségünk, ami a NetBIOS neveket 
egy központi adatbázisban tartja. 


Windows Internet Name Service 

Ilyen szolgáltatás a Windows NT Serveren vagy Windows 
2000 Serveren futó WINS. A WINS kiszolgáló egy olyan 
azokat egy JET típusú adatbázisban tárolja, frissíti. 
Ügyféloldalon szükséges egy WINS kliens, amit a Microsoft 
TCP/IP implementáció tartalmaz. Csak annyit kell beállíta- 
ni, hogy mi a WINS kiszolgáló TCP/IP címe és már kész is. 
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IP Settings ] DNS. WINS ] Options ] 


7 WINS addresses, in order ol use: 


Ed. Remove E 


If LMHOSTS lookup iz enabled, it appíies to all connections for which 


TCPAP is enabled. 
Import LMHOSTS... 





7. Enable LMHOSTS lookup 


NetBIOS setting 

G Default 
Use NetBIOS setting rom the DHCP servet. If static IP address ís 
used or the DHCP server does not provide NetBIOS setting. 
enable NetBIOS over TCP/IP. 

C Enable NetBIOS over TCPAP 


€ Digable NetBIOS over TCP/IP 


Cancel 








OK 





9 TCP/IP protokoll WINS adatlap 


Tehát amennyiben van egy WINS kiszolgálónk és egy he- 
lyesen konfigurált WINS ügyfelünk, a munkaállomás re- 
gisztrálja az IP címet a WINS adatbázisában minden indu- 
láskor, majd minden sikeres leálláskor ki is veszi onnan 
(deregisztrálja) . A WINS kiszolgáló adatbázisa olvasható is 
a WINS ügyfelek számára, és amennyiben a kliens számító- 
gép keresi az srvO1-hez tartozó IP címet, előbb megkérde- 
zi a WINS kiszolgálót, hogy milyen IP cím tartozik a név- 
hez. Természetesen azt azért nem mondhatjuk, hogy a 
Broadcast típusú üzenetszórásra már nincs is szükségünk, 
mert ez nem így van. A WINS kiszolgáló adatbázisa csak a 
megfelelően beállított gépekről tartalmaz adatokat, és 
csak az általa regisztrált címekről (természetesen lehet 
több WINS kiszolgálót szinkronizálni egymással, és akkor to- 
vábbi WINS kiszolgálók által regisztrált címekről is lesz infor- 
máció). Tehát ha az srvO1 nem WINS kliens, vagy nincs 
rendesen beállítva, abban az esetben azt a WINS adat- 
bázisban nem is lehet megtalálni - csak Broadcast típusú 
üzenetszórással. Ezenkívül, létezhetnek még olyan esetek 
amikor nem kell használni a WINS adatbázist, például: 

I Ha a keresett név a sajátgép neve 

"Bi Ha nem NetBIOS név amit keresünk 

Meg kell meg említeni, hogy a WINS kiszolgáló szolgálta- 
tásnak van egy helyileg minden kliens gépen elérhető ki- 
csinyített változata - egy fájl. A 


itSystemRoot$ilSystem32iDriversVetc 


könyvtár alatt található az lmhosts nevű fájl. Ebbe kézzel 
felvehetünk NetBIOS neveket és IP címeket, amiket kliens- 
gépünk majd képes lesz feloldani. Használata csak speciá- 
lis esetekben ajánlott, mivel az lmhosts fájl csak az adott 
gépen érvényes, és ha a hálózatunk minden számítógépén 
azonos névfeloldást szeretnénk használni, akkor azonos 
lmhosts fájlt kell(/ene) használni. Továbbá az lmhosts fájl 
statikus, minden változtatás kézimunkázást igényel. 

Tehát nem kell használnunk a WINS adatbázist akkor, ha a 
NetBIOS gépnév megegyezik a sajátgépünk nevével. Ez 
azért lehetséges, mert minden számítógép a saját nevéről 
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tudja, hogy az a sajátja. A másik lehetőség pedig az, ami- 
kor nem NetBIOS névről van szó. Emlékszünk milyen név le- 
het meg? Például FODN, azaz DNS név (www.kutyafule.hu)! 
Azt nem a WINS adatbázisban kell keresni ... de honnan 
tudhatja a gépünk, hogy mi a NetBIOS név és mi FODN? A 
NetBIOS név maximum 15 karakter hosszú lehet, az ennél 
hosszabb nevek biztosan FODN nevek lesznek, amiket a DNS 
kiszolgálón kell keresni. Olvastunk már pár szabályt, amiből 
a NetBIOS névfeloldás sorrendjét is megállapíthatjuk: 











A név a I I Talál a 
saját WINS ilyet? 
nevem ől 

Hurrá! 
l N Megvan "7 ] N 

Esetleg a I I Megvan az 

gyorsítótárban t Imhosts 
van? fájlomban? 
EN LN 
Hosszabb, N I 
mint 15 Broadcastra 
karakter? válaszol? 
11 LN 
DNS! Nincs meg 


5 A NetBIOS névfeloldás blokkdiagramja 


Befolyásolhatjuk kliensünket, hogy milyen sorrendben és 
hol keressék a neveket. A NodeType határozza meg egy gép 
számára, hogy milyen sorrendben próbálja meg feloldani a 
kéréseket. A következő node-type-ok léteznek: 

"8 B-node (Broadcast): minden kérést Broadcasttal próbál 
meg feloldani. Ha ez nem sikerül, az LMHOSTS fájlba is 
belenéz 

8 P-node (Point-to-point-WINS): a kliens minden kérést a 
WINS kiszolgálóhoz küld, a névfeloldás során más ki- 
szolgálót nem használ. Még kínjában sem broadcastol. 
Nagyon rossz módszer, mert ha nincs elérhető WINS ki- 
szolgáló, a gép nem lát semmit a hálózaton. 

8 M-node (Mixed-B--P): A P és a B típus keveréke. A kliens 
először broadcastol, majd ha sikertelen a feloldási kísérlet, 
akkor a WINS kiszolgálóhoz fordul. Nincs DNS kiszolgáló a 
névfeloldásban, természetesen a 15 karakternél hosszabb 
neveket nem is tudja a rendszerünk ekkor feloldani. 

"2 H-node (Hybrid-P4-B4.DNS): Hasonló az M-node-hoz csak 
a sor végén ott van a DNS kiszolgáló. Természetesen ha 
egy név hosszabb mint 15 karakter azonnal a DNS ki- 
szolgálóhoz továbbítja a kérdést. 
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5 H-node-type ügyfél 


Az ipconfig /all paranccsal könnyen lekérdezhetjük gépünk 
node-type-ját. 

Egy alapértelmezésben telepített kliens b-node típusú, ilyen- 
kor nincs WINS, vagy DNS kiszolgáló használatára beállítva. 
Amint egy WINS kiszolgáló címét beállítjuk, a gép egyből átáll 
h-node-ra. A node-type a DHCP kiszolgálóval központilag sza- 
bályozható minden munkaállomáson A fenti lépések mindegyi- 
két megbeszéltük, egy kivételével. Nem beszéltünk még az 
FODN-ről. Nézzük meg most azt is egy kicsit közelebbről! 


FODN és annak feloldása 

A FODN a fully gualified domain name rövidítése, ami any- 
nyit jelent, hogy teljesen hitelesített név. Azért van szükség 
erre, mert ez teszi lehetővé, hogy egy név valóban egyedi 
legyen. Míg a NetBIOS is egyedi, az FODN is az, csak a ha- 
táskörük más egy kicsit. Az Internetes kommunikáció során 
a NetBIOS névteret nem használjuk, ennek több oka is van. 
Az egyik a névtér tulajdonságából adódik: a NetBIOS névtér 
sík, hierachia bevezetésére nem alkalmas. Ez azt jelenti, 
hogy párezer gépen túl ,használhatatlanná" válik, mert 
szinte képtelenség olyan sok teljesen egyedi, de teljesen ér- 
telmes gépnevet kiválasztani. Az FODN névnél többszörös 
összekapcsolást is csinálhatunk pl.: mail.geniusgroup.hu. 
Ha a NetBIOS név lenne az Internetes kommunikáció elfo- 
gadott névkonvenciója, akkor a , mail" nevet csak egyetlen 
egy gép használhatná :-) Valljuk be, ez egy kicsit szegényes 
megoldás lenne. E helyett használjuk a DNS-t, amiben 
összekapcsolhatjuk egy host nevét egy domainnévvel, és ez 
a hosszú név biztos, hogy egyedi lesz, továbbá a , mail" host- 
név használható bármely tartománynév esetén - mint ahogy 
minden faluban lehet Kovács Pista. Tehát mint láthatjuk, az 
FODN némileg hasonlít a NetBIOS névre és a NetBIOS név- 
feloldásra. Az FODN feloldásakor szintén az IP címet keres- 
sük, csak ilyenkor nem a WINS kiszolgálóval kommuniká- 
lunk, hanem a DNS-sel. A Windows 2000 operációs rendszer 
alap névfeloldási rendszerkent már a DNS-t használja (lassan 
leszokunk a NetBIOS-ról) . Sokat, rengeteget változott a Win- 
dows NT 4.0-ban található DNS Serverhez képest a Windows 
2000 azonos szolgáltatása. Míg NT 4.0-ban a DNS kiszolgá- 
ló adatbázisa egy statikus adatbázis volt, addig a Windows 
2000-ben található DNS kiszolgáló képes a WINS-hez hason- 
lóan dinamikus frissítésre és a DNS nevekhez tartozó szol- 
gáltatásokat is képes eltárolni. Mi több, az Active Directory 
egyik alappillére a DNS kiszolgáló. Mit jelent ez? Gyakorlati- 
lag egy homogén Windows 2000-es rendszerben nincs szük- 
ség többé a WINS kiszolgálóra, a NetBIOS kommunikációra. 
Használhatjuk helyette az FODN-t mert a DNS kiszolgálóink 
adatbázisában minden szükséges információt megtalálunk! 
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Azért a Windows NT 4.0-ban is volt lehetőségünk az FODN- 
ek használatára a hálózatunk minden számítógépének 
elérésére. A DNS kiszolgálók képesek a WINS kiszolgálóval 
történő kommunikációra. Ez azt eredményezi, hogy ha egy 
DNS zóna alatt a keresett host nem elérhető, a DNS kiszol- 
gáló a hostot megpróbálja feloldani a WINS adatbázisból. 
Így nem szükséges minden gépet felvenni manuálisan a 
DNS zónába. Természetesen a Windows 2000 alapú DNS ki- 
szolgáló támogatja a dinamikus frissítést és így nem szük- 
séges a WINS-LOOKUP használata. (Egyébként a DNS-WINS 
együttműködés problémákat is okozhat, mert egy WINS típu- 
sú rekordba kerül be, hogy hol van a WINS Server. Ezzel az 
a baj, hogy a DNS szabványok nem tartalmaznak WINS re- 
kordtípust. Van A, meg MX, meg NS - de WINS az NINCS! Ha 
egy ilyen , fertőzött" zónafájlt valamilyen , ellenséges" DNS 
Serverre szeretnénk replikálni, az jó eséllyel visszautasítja a 
számára értelmezhetetlen adatot! Láttam én már ilyet!) 
Áttekintettük a névfeloldás témakörét. Úgy érzem, hogy ezen 
ismeretek elengedhetetlenül fontosak egy sikeres TCP/IP hiba- 
keresés eseten. Ha hibakeresés akkor hibakeresési eszközök: 


Ping 

ICMP kommunikáció, sok hasznos kapcsolóval. Használatá- 
val két gép közti ICMP kommunikáció megléte ellenőrizhe- 
tő. Windows 2000-es változata már egy statisztikát is kö- 
zöl a felhasználóval. Vigyázat, MINDIG először DNS név- 
feloldást választ, még rövid nevek megadása esetén is! Ha 
irgalmatlanul lassan, de mégiscsak válaszol, akkor a követ- 
kező történik: Vár-vár-vár a DNS-re, majd X idő múlva 
megunja, és áttér a NetBIOS feloldásra - ami akár 
Broadcasttal is sikerülhet! 

Használata: ping állomásnév 


Tracert 

Hasonlóan a ping-hez itt is ICMP kommunikáció meglétét 
ellenőrizhetjük. Amiben több, az az hogy a két gép közöt- 
ti összes útválasztó meglétét is láthatjuk. 


Pathping 

Csak Windows 2000 alatt elérhető eszköz. A ping és a tracert 
parancsok keveréke és mind két eszköz jó tulajdonságait 
magában hordozza. 


Nbtstat 
A TCP/IP protokoll, a NetBIOS Cache és a hálózati csatoló 
tulajdonságai kérdezhetők le vele. Például: 


NBTSTAT -c 
A parancs hatására megjelenik a (két hálózati kártyás) gé- 


pem NetBIOS Cache tartalma, benne nemcsak a nevek, ha- 
nem az az ominózus 16. bájt, a szolgáltatáskód! 
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5 A NetBIOS Cache tartalma 


Az alábbi táblázatban láthatók a legfontosabb szolgálta- 
táskódok: 


0x00 Workstation szolgáltatás 
0x03 Messenger 

0x20 Server 

0x1c Tartományvezérlő 











A teljes NetBIOS szolgáltatáslista az [1] címen olvasható 
(NetBIOS suffixes). Sohanemvolt-hackerként ehhez annyit 
tennék hozzá, hogy a -a kapcsolóval távoli gépek NetBIOS 
Cache-e is lekérdezhető, és például a 0x03 rekordra pil- 
lantva rögtön látszik, ki van bejelentkezve - hisz 
Messenger rekordot a felhasználó regisztrál. Talán nem vé- 
letlen, hogy a Google erre a keresésre ,netbios tcp port" 
első találatként egy hackerszájtot dob fel [2] :-). A 
NetBIOS szolgáltatások Internet felőli láthatóságát célsze- 
rű korlátozni! Ne engedje át tűzfalunk a 135-139 portokat! 


Összegzés: 
A névfeloldást és a névteret megfelelően meg kell tervezni 
egy tartomány építése előtt. Olyan terület ez, ami nagyon 
befolyásolja a géppark helyes működését. Szerteágazó és 
nehéz feladat. Cikkem során ennek csak egy kis részébe 
nyertünk bepillantást, lényegesen nagyobb feladat mint 
amilyennek ez elsőre látszik. Szeretném megjegyezni, hogy 
hiába ajánlás a WINS elhagyása és 10 számítástechnikusból 
x azt mondja, hogy ne használjuk a WINS-t és vele együtt 
a NetBIOS-t, én azt mondom, hogy kompatibilitási okok, il- 
letve a redundancia miatt a WINS megmaradhat. Sokan fél- 
nek a WINS-től, de úgy gondolom ahogy a királykobra is ve- 
szélyes, mégis a mérgéből komoly gyógyszereket készíte- 
nek, a WINS is lehet hasznos, ha megfelelően kezelik. 
Reményeim szerint közelebb kerültünk egy kicsit a név- 
feloldási folyamat megismeréséhez és az elméleti tudás 
gyakorlatba való átültetésével a napi munkánk egy kicsit 
könyebb lesz. Aki pedig ezt mind tudta, azoknak pedig egy 
könnyed olvasmány volt. 
Harmath Zoltán 
zoli(ogeniusgroup.hu 
MCSE, MCP--i 


[att TI ErZA Ag AL HITT ő 


[1] http://support.microsoft.com/support/kb/articles/0163/4/09.asp 
[21 http://www.networkice.com/advice/Exploits/Ports/ 
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Remote 
Installation 


Services (I. rész) 


Mi is a RIS valójában? Egy Windows 2000 beépített eszköz, amely 
az ügyfélgépek üzembehelyezését hivatott megkönnyíteni. 
Segítségével úgy telepíthetünk Windows 2000 és Windows 
XP munkaállomásokat - amelyekben sem floppy, sem CD 
nincs (de egy HDD azért persze van) - hogy nem is kell köz- 
vetlen rendszergazdai beavatkozás. 

A Windows NT 4.0 környezetben megismert, asztali gépek távo- 
li telepítések lehetőségeihez képest mindenképp nagy előrelé- 
pés ez! Megvalósítható hogy maga a felhasználó akár telefonos 
segítséggel is el tudja indítani a telepítést, és valóban hozzá 
sem kell nyúlnia, pikk-pakk minden szükséges programmal fel- 
vértezett Windows 2000 munkaállomás a végeredmény. 
Mielőtt azonban az égbe emelném ezt a szolgáltatást, meg 
kell jegyeznem, hogy komoly korlátai is vannak, látni fog- 
juk hogy egy sor követelménynek kell megfelelni ahhoz, 
hogy egyáltalán használni tudjuk. Ha megteremtjük a felté- 
teleket, akkor senki nem tarthat vissza attól, hogy valóban 
egységes, központilag szabályozott, rendezett munkaállo- 
más parkot alakítsunk ki. 


Mi megy? Mi nem megy? 

Sajnos a RIS csupán Windows 2000 Professional vagy Windows 
XP telepítését teszi lehetővé, de azt legalább kétféle módon. 
Az egyik az ún. image alapú telepítés, a másik a scriptalapú. 
A RIS-sel történő scriptes Windows 2000 Professional telepí- 
tés - ezt nevezik CD alapú telepítésnek is - sokban hasonlít 
a régről ismert hálózatos felügyelet nélküli telepítéshez, hisz 
egy kiszolgálóról a telepítéshez szükséges állományok az 
ügyfélre kerülnek, majd onnan a válaszokat tartalmazó állo- 
mány alapján telepítésre kerül az operációs rendszer és 
egyéb programok, ha mi is úgy akarjuk. Különbség a kettő 
közt a megoldás módjában van. Főként az gyorsítja a RIS-es 
telepítést, hogy PXE képességekkel rendelkező hálózati kár- 
tyával megáldott gépekez nem kell floppy vagy CD a telepí- 
téshez. Ebben az esetben a RIS maga csak az operációs rend- 
szert telepíti, a szükséges programok telepítéséről nekünk 
kell gondoskodni, persze ez is megvalósítható rögtön az ope- 
rációs rendszer telepítése után, de ez plusz munkát igényel. 
Az imagealapú telepítés Windows NT környezetben csak 
3rd party eszközök segítségével volt megvalósítható, a RIS 
viszont lehetővé teszi ezt is - ezt hívják RIPREP telepítés- 
nek -sőt, a Windows 2000 plug and play rendszere révén az 
etalonként használt, és a később telepített gépeken csak a 
HAL kell, hogy azonos legyen (ACPI vagy nem ACPI), tehát 
nem szükséges teljesen egyforma hardverelemek megléte. 
Ez az image nem egy gigantikus állomány (mint általában 
más gyártóknál) , hanem tulajdonképp a háttértár első par- 
tíciója szőrőstül-bőröstül felkerül a kiszolgálóra a 
RIPREP.EXE futtatása során. Hátránya tehát, hogy csak egy 
partíció telepítését teszi lehetővé, tehát ha valaki előké- 
szít egy masinát, számoljon vele, hogy csak a boot ill. sys- 
tem partíciót fogja tudni később telepítéshez használni; 
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viszont nem korlátozza a CD-ROM lemezek limitált tároló 
kapacitása a telepítőkészlet előállítását. A RIS hátrányos 
tulajdonsága az is, hogy nem tesz lehetővé operációs rend- 
szer frissítést, csak teljesen szűz telepítés végeztethető el 
vele. Ellentétben a scriptes telepítéssel, ezzel a módszerrel 
a RIS egy menetben telepíti az operációs rendszert és a 
rajta lévő programokat, hisz a mintaként használt gép egy 


használni a telepítésekben. 


Szükséges szolgáltatások 

Még mielőtt belevágunk a telepítésekbe tényleg fontos, 
hogy a működéshez szükséges feltételek meglegyenek, 
egyébként vagy semmi nem fog működni, vagy később ke- 
rülünk szembe problémákkal. 

Telepítés során az ügyfél DHCP-től kapja meg IP címét, ezért 
mindenképp kell DHCP kiszolgáló, ez azonban nem kell hogy 
Windows 2000 legyen. Miután a gép kapott IP címet, a DNS ki- 
szolgálóhoz fordul hogy Active Directory tartományvezérlőt ta- 
láljon, tehát egy DNS is kell a hálózaton, méghozzá olyan, 
amely támogatja az SRV rekordokat és lehetőleg a bejegyzések 
dinamikus frissítését is (ez utóbbi nem feltétlen szükséges) . Ha 
már az Active Directorynál tartunk: csak akkor fog Active 
Directory tartományvezérlőt találni az ügyfél - akitől megtud- 
hatja ki is a RIS kiszolgáló - ha van Active Directory. Hogy ne 
keverjem tovább a dolgokat, kell tehát Active Directory, DHCP 
és DNS a RIS működéséhez. Ez nem azt jelenti, hogy a távoli 
telepítéseket végző kiszolgáló kell legyen a tartományvezérlő, 
a DHCP és a DNS kiszolgáló is egymagában, hanem azt, hogy 
a hálózaton elérhetőnek kell lennie mindhárom szolgáltatás- 
nak. Bőven elég, ha a RIS egy tagkiszolgálón fut. 

Szigorúan ajánlott azonban külön partíció létrehozása a távo- 
li telepítésekhez használt állományok tárolására, mert telepí- 
tés után az adott partíciót a SIS (Single Instance Store) veszi 
uralmába. Később még szólok ennek működéséről, most csak 
annyit, hogy ennek segítségével egy rakás helyet spórolunk, 
mert minden többször előforduló állomány egyszer foglalja 
majd a helyet a RIS által használt partíción. Fogadjuk meg és 
készítsünk külön NTFS partíciót a telepítés előtt. A beállítás- 
hoz használt varázsló nem engedi, hogy system vagy boot 
partícióra kerüljön a Remotelnstall könyvtár, de nem figyel- 
meztet, ha az egyébként megjelölt partíción vannak más ál- 
lományok. A partíció legalább 2Gb-os legyen, bár a telepítés 
nem fog ennyit elhasználni. Nem nehéz megtölteni, ha több- 
féle telepítést készítünk elő, és mozgatása nem egyszerű a 
latosan, hogy a titkosítás (EFS) és a SIS nem szeretnek kö- 
zösködni, nem működnek ugyanazon a partíción. 


Ügyféloldali követelmények 


A munkaállomásként használt számítógépekbe olyan háló- 
zati kártya kell, amelyiken van Pre-Boot eXecution 
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Environment (PXE) ROM. Ez teszi lehetővé, hogy az ügyfél 
a kártyáról bootolva indítsa a telepítést. 

Legkönnyebb dolgunk akkor van, ha a munkaállomások 
megfelelnek a PC98 szabványnak, ugyanis ilyenkor a hálóza- 
ti kártyán helyből ott van a PXE ROM. Csupán a BIOS-ban 
kell beállítanunk a bootsorrendet, előre téve a hálózatos 
boot lehetőségét, majd a következő boot során már alkal- 
mas a gép arra, hogy a RIS kiszolgálót elérjük vele. Ha nem 
ilyen masináink vannak, akkor is van mód a RIS használatá- 
ra, ilyenkor PXE emulátort tartalmazó floppy-t gyárthatunk. 
Sajnálatos módon azonban a támogatott hálózati kártyák 
köre meglehetősen szűk. Kizárólag néhány PCI hálózati kár- 
tyához van mentőöv, sem az ISA - hiába plug and play -, 
sem a PCMCIA hálózati kártyák nem támogatottak. 

A RIS-hez szükséges boot floppy a Remotelnstallyadmin 386 
könyvtárban található rbfg.exe segítségével készíthető. Egy 
olyan floppy készül, amely az összes (mind a 25 :-( ) támo- 
gatott hálózati kártyával rendelkező géphez használható. A 
lemezen egy picike fájlt (89,3 kilobájt) találunk, mely nem 
más, mint a boot ROM tartalma. Ebből következően a támo- 
gatott kártyák körét házilag bővíteni nem lehet, mert csak 
olyan jó nekünk, ami tudNA bootolni ROM-ról - csak éppen 
nincs bedugaszolva neki olyan. 


B Windows 2000 Remote Boot Disk Generator Ki Ei 
To create a remote boot disk for use with the Windows 2000 Ftemote 
installation Service, insert a formatted Iloppy dísk into eithet drive A or 
dííve B, select the destination diive, and then click Create Disk. 

The remote boot disk can be used only with computers that contain 


supported PCI-based network adapters. For a list of supported adaptets. 
click Adapter List. 


Destination drive. 


About Adapter List Close 


5 A Remote Boot Disk Generator, RBFG.EXE 


Akár van PXE boot ROM a hálózati kártyán, akár a fenti 
módszerrel készített floppyt használjuk, ugyanúgy történik 
a telepítés elindítása: a PXE segítségével. A floppy csupán 
emulálja a PXE környezetet a hálózati kártya helyett. 


Mi is a PXE és hogy működik? 

Ha mondjuk masinában levő háttértárról indítjuk a számí- 
tógépet, akkor a BIOS betöltése után - a boot sorrendben 
beállítottaknak megfelelően - az első eszközön (mondjuk 
az első háttértáron) megkeresi a bootszekort, betölti, majd 
az ott találtaknak megfelelően elindul az operációs rend- 
szer, vagy annak menüje. 

A PXE - teljes nevén Pre-Boot eXecution Environment - ha a 
BIOS boot sorrendjében a hálózat van legelöl, illetve meg 
van engedve a hálózatról való boot, a háttértárat vagy a 
floppyt is megelőzve a hálózaton keresztül a kiszolgálón el- 
helyezett boot szektort használva indítja a számítógépet. 
Nézzük, hogy is csinálja mindezt RIS kiszolgáló esetén! Az 
alábbi esetben külön DHCP és RIS kiszolgáló van a hálózaton. 
1. lépés 

Az ügyfél broadcast DHCP Discover üzenetet küld a szabvá- 
nyos DHCP portra (67), DHCP és RIS kiszolgálót keresve. 
Az üzenetnek opcionális mezője is van, amelyben az ügy- 
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fél azonosítója (GUID), a hálózati kártya, valamint a mun- 
kaállomás architektúrájának azonosítója szerepel. 


PXE Operation Client - Server Interaction 


DHCP Discover on Port 67 


me contains (PXE Client extension tags) hi 
EA DHCP Discover on Port 67 [alte 
contains (PXE Client extension tags) Uld 


CStep1— 


DHCP offer on Port 68 
contains Dynamic IP address 4 


44— other DHCP option tags 0 


WA Extended DHCP offeron port 
63 contains (PXE Server extension tags) 
Ctient IP address is null 


DHCP Reguest on Installation Server 
port 67 contains 

(PXE Server extension tags) 

(4 Other DHCP option tags) 


8 6 
N DHCP Ack reply on Port 60 e 
DHCP Reguest to BINL Service port 4011 
contains: (PXE Server extension tags) 
cse (4 Other DHCP option al 
(CStep7) — E 
DHCP Ack süzazset B] on Clients Port pestdoeerz] 
VE contains: (PXE Server extension tags) Laves 


7 (contains the Nt 
tegy Doriosá Network Bootstap Program file name) 


Network Bootsrap Program Downloads 
CStep8) Reguest on TFTP port 6——p- 
"V Network Bootsrap Program bolond 


to Clients port 


Csepp 
CStep5 


PxXE Installation 
client Server 


0 A PXE működése 


2. lépés 

A DHCP kiszolgáló egy ajánlattal válaszol az ügyfélnek, 
amely tartalmazza az IP címet és más DHCP opciókat. Most 
jön a csoda. A DHCP Discover üzenetre a RIS kiszolgáló is 
válaszol (sic!), PXE kiszolgálóként megadja saját IP címét. 
(Emiatt kell a RIS gépet ugyanúgy, és ugyanott Authorizálni, 
mint a DHCP Servereket: a DHCP Administratorral!) 

Ezen a ponton más DHCP és RIS kiszolgálók is válaszolhat- 
nak az ügyfélnek. Ezek az üzenetek szabványos DHCP para- 
métereket tartalmaznak - az ügyfél IP címét, és amit a rend- 
szergazda még beállított. Ha a DHCP a RIS kiszolgálón van 
telepítve, akkor a telepítő kiszolgáló által küldött DHCP vá- 
lasz szintén tartalmazza a szabványos DHCP paramétereket 
(ez gyakorlatilag az ügyfél IP címét jelenti) . 

Az ügyfél először olyan DHCP csomagot vár, amely vagy 
csak IP címet, vagy IP címet és egy PXE rendszertöltő ki- 
szolgáló IP címét tartalmazza. Megjegyzi azonban a RIS ki- 
szolgáló IP címét is, ezt később használni fogja. 

3. lépés 

Az ügyfélnek - miután feldolgozta a csomagokat - egy 
újabb üzenettel (a DHCP Reguest csomaggal) kérnie kell a 
számára felajánlott címet a DHCP kiszolgálótól. 

4. lépés 

A DHCP kiszolgáló nyugtázza ügyfél a kérését. 

Vegyük észre, hogy eddig a pontig nem más történt, mint 
szabályos DHCP által történő IP címkiosztás (plusz némi ol- 
dalról belekotyogás a RIS kiszolgáló által) . 

5. lépés 

Az ügyfél egy DHCP Reguest csomagot küld a RIS kiszolgá- 
lón működő BINL szolgáltatásnak a 4011-es portra. A RIS 
kiszolgáló IP címét a 2. lépésben már megjegyezte. Ez a 
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csomag ugyanaz, mint az első lépésben leírt DHCP Discover 
csomag, annyi különbséggel, hogy ez most DHCP 
Reguestként van kódolva. Jó mi? 

6. lépés. 

A telepítő kiszolgáló BINL szolgáltatása egy DHCP 
Acknowledge (nyugtázás) csomagot küld vissza az ügyfél- 
nek, szintén a 4011-es portra, amelyben megküldi az indí- 
táshoz használt állomány nevét - RIS esetén startrom.com 
- és helyét, valamint az ügyfél egyedi azonosítóját (GUID). 
7. lépés. 

Az ügyfél szabványos TFTP használatával letölti a végre- 
hajtható állományt. Az, hogy melyik fájlt tölti le, valamint 
hogy a letöltött kód hol fog elhelyezkedni a memóriában, 
az ügyfél CPU architektúrájától függ. 

8. lépés. 

A PXE ügyfél megkezdi a letöltött kód végrehajtását. 

A fenti eset akkor megy végbe, amikor a DHCP kiszolgáló és a 
RIS kiszolgáló külön számítógépekről szolgálja ki az ügyfeleket. 
Ha a RIS kiszolgáló egyben DHCP is, akkor sokkal rövidebb ez 
a folyamat, mert a második lépésben a DHCP kiszolgáló hely- 
ből elküldi a RIS használatához szükséges paramétereket is. 
Az ügyfél a harmadik lépésben a DHCP Reguest csomagban 
kéri az IP címet, az IP beállításokat és a RIS használatához 
szükséges paramétereket is egyben, ezután a DHCP - ami ugye 
RIS kiszolgáló is -, egy menetben megküldi mind az összes 
kért paramétert egy DHCP nyugtázásban (Ack) csomagban. 


Működés közben 

OK. Ez volt maga a PXE, de hogy működik mindez RIS környe- 
zetben, amikor mi a munkaállomás előtt ülünk? Hogyan lesz 
ebből működő óperenciás rendszer? Hát nagyjából így: 


a 
ZA 
36 


5 A munkaállomás telepítésének folyamata 





DHCP RIS 
Server — Server 


s 
1 
5 

















RIS Client 


A munkaállomáson (miután beállítottunk hogy először a háló- 
zatról próbáljon indulni) a BIOS betöltése után a képernyőn 
megjelenik a gép MAC címe, és a rendszer megkezdi az IP cím 
kérését, és a RIS kiszolgáló keresését. Az előzőekben tulajdon- 
képp arról volt szó, amit itt az 1. nyíl jelöl, az ügyfél megbe- 
széli a DHCP kiszolgálóval, hogy az adjon neki IP címet és min- 
dent, amit a rendszergazdi beállított a DHCP kiszolgálón. 

A RIS kiszolgáló az Active Directoryhoz fordul (2. nyíl) és leel- 
lenőrzi a számítógép accountját a tartományban, mindezt a 
gép által a DHCP Discover csomagban elküldött azonosítója 
alapján teszi (GUID). Megnézi van-e már számítógéphez 
Computer Account. Ha talál, akkor később azt fogja használni, 
ha nincs az sem baj, lehet létrehozni később a telepítés során. 
Ha talált RIS kiszolgálót és ott minden rendben, felszólítja 
a felhasználót az F12 funkciógomb lenyomására. A felhasz- 
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nálónak 4 másodperce van erre, egyébként a rendszerindí- 
tási lista következő eleméről folytatódik a rendszer indítá- 
sa. Bizonyos rendszerekben úgy is be lehet állítani a PXE 
egyeztetést, hogy a felhasználónak meg kelljen nyomnia az 
F12 funkciógombot. Ebben az esetben a felhasználónak két- 
szer kell megnyomnia az F12-t - egyszer a PXE egyeztetés 
aktiválásához, és másodszor, amikor a RIS kiszolgáló vála- 
szol. Ha minden ügyfél támogatja az F12-t, akkor a 
Startrom.com fájlt az Oschooser4386 könyvtárban kicserél- 
hetjük a Startrom.n12 fájlra, így nem kell az F12-t másod- 
szor is megnyomni. 

Tehát az F12 után a kiszolgálóról letöltődik TFTP-vel a 
startrom.com (3. nyíl) ami tulajdonképp a boot szektor 
majd az első CIW - Client Installation Wizard - képernyő a 
Welcome.osc - köszönti a felhasználót. 

Ezután a bejelentkezési képernyő (Login.osc) jelenik meg. 
A képernyők a választásoknak megfelelő sorrendben töltőd- 
nek le. Miután a felhasználó bejelentkezett, a RIS kiszolgá- 
ló a megadott felhasználói név és jelszó alapján ellenőrzi az 
Active Directoryban, mit ajánlhat fel a következő képernyő- 
kön (az adott felhasználó melyik operációs rendszert úgy ér- 
tem melyik telepítőkészlett telepítheti a sok közül, ami a ki- 
szolgálón található. 4. nyíl). 

Amennyiben a felhasználónak az van beállítva, hogy ő ma- 
ga nem választhat, akkor számára a Group Policy segítségé- 
vel megjelölt telepítőkészlet fog települni, ha azonban van 
választási lehetősége, akkor az alábbiak (5. nyíl): 


TENTERI continue 


TF1) help 


F3] restart conputer 


a Választási lehetőségek 


0 Automatic Setup (Automatikus telepítés): A felügyelet 
nélküli alapértelmezett beállításokkal telepíti az operációs 
rendszert, a felhasználótól csak a telepítéshez használan- 
dó telepítőkészlet kiválasztását kéri. Az automatikus tele- 
pítéshez használt Setup Information File-t (SIF) testre- 
szabhatjuk szervezetünk igényeinek megfelelően. 

B Custom Setup (Egyedi telepítés): Lehetővé teszi a fel- 
használóknak, hogy megadják a számítógép nevét és 
azt, hogy az újonnan létrehozott Computer Account ob- 
jektum (CAO) melyik 0U-ba kerüljön. Ha ezek a mezők 
üresen maradnak, akkor RIS kiszolgáló által megadott 
alapértelmezések lépnek életbe (mint az automatikus 
telepítés esetében). Fontos megjegyezni, hogy ha az 
egyedi telepítés során megadott név és hely megegye- 
zik egy létező CAO nevével és helyével, és az ügyfél 
GUID-je egyezik a létező CAO GUID-jével, akkor a léte- 
ző CAO-t a Telepítő felhasználja. Ha a GUID, a név és a 
hely közül csak egy egyezik meg, akkor , duplicate 
name" vagy ,duplicate GUID" hibaüzenetet kapunk. 

B Restart a previous Setup attempt (Megszakadt telepítés 
folytatása): Ha a telepítés még a grafikus mód (GUI) 
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elérése előtt megszakad (például áramszünet vagy a há- 
lózati kapcsolat hibája miatt), ennek az opciónak a ki- 
választásával folytathatjuk a félbeszakadt telepítést, 
így a felhasználó átugorhatja a már kitöltött képernyő- 
ket. A Telepítő indulása után a használt válaszfájl be- 
kerül egy könyvtárba a távoli telepítőkészleteket tartal- 
mazó köteten (ez a távoli telepítő könyvtárfájának Tmp 
könyvtára). A fájl neve a telepítést végző rendszer 
GUID-je lesz (vagy 24 darab nulla plusz a MAC címe, ha 
az ügyfél a PXE-emulátor floppylemezt használva indult) , 
kiegészítve a .sif kiterjesztéssel. 

PI Maintenance and Troubleshooting (Karbantartás és hibael 
hárítás): A más gyártók által készített karbantartó és 
diagnosztikai eszközökhöz biztosít hozzáférést. Ilyen 
például a BIOS frissítése vagy a távirányítás. 

A következő képernyőn megjelenik a választható operációs 

rendszer telepítőkészletek listája. Ha csak egy van, akkor az 

automatikusan kiválasztódik, és folytatódik a telepítés. 

Ezután egy üzenet figyelmeztet bennünket, mely szerint a 

program megformázza a helyi merevlemezt és a rajta lévő 

adatok elvesznek, kivéve, ha a SIF tartalmaz olyan bejegyzést, 

hogy ne particionálja újra a merevlemezt. (Ez a bejegyzés a 

SIF fájlban a Repartition z Yes]INo. Ha a No értéket adtuk meg, 

akkor a program nem formázza meg a lemezt és a figyelmezte- 

tő üzenet sem jelenik meg.) Az ENTER lenyomása után a kö- 
vetkező információ jelenik meg az utolsó képernyőn: 

0 A létrehozott CAO 

0 A GUID 

0 Atelepítőkiszolgáló neve (az a RIS kiszolgáló, amelyről 
a telepítőkészlet származik) 

Amennyiben csak elő akarjuk készíteni a számítógépet, ak- 
kor ezen a ponton kikapcsolhatjuk. Ennek a módszernek a 
használatával kicsomagoljuk a gépet a dobozából, elindít- 
juk, hogy létrejöjjön a CAO-ja, majd átadjuk a felhasználó- 
nak. Így elkerülhető a CAO felhasználó általi elírása. A RIS 
kiszolgáló észre fogja venni, hogy a GUID már hozzá van 
rendelve egy CAO-hoz és az abban levő információk fel- 
használásával fogja befejezni a telepítést. 

Még egy ENTER és elindul a telepítés (6. nyíl), innen már nincs 

visszaút. Körülbelül egy óra kell ahhoz, hogy települjön az ope- 

rációs rendszer, persze ez az idő változhat a hálózat sebességé- 
től, ill. a gép egyéb paramétereitől függően. A RIPREP módszer- 
rel előkészített telepítések esetén hamarabb végez. 


Kiszolgálótelepítés 

Készítsünk RIS Servert! Maga a telepítés nem nagy kunszt: 
mint a legtöbb Windows 2000 szolgáltatást, az 
Add/Remove Programs -  Add/Remove Windows 
Components menüjéből telepíthető a RIS. 
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Windows Components Wizard Eg 


Windows Components 
Youcan add or remove components of windows 2000. 





To add or remove a component, ckek the checkboz. A shaded box means that only 
patt of the component wil be installed. To see whalts included in a component, click 


Delals. 
Loraponents: 
4 á70ther Netwotk Fde and Piint Services 00MB a 
447 Remote installation Services 1.4 MB 
Ál Remote Storage 33MB 
2 Verminal Services 14.1 MB 
Á Terminal Services I irensinn N4AMR OT 


Descúptiorc. Instalis a certification authority [CAJ to issue certificates for use with 


pubc key security applications. 
Total disk space reguíred: 0.9 MB Detai:. 
Space available on disk: 1412.9MB E 


5 Add/Remove Windows Components 

A RIS-t telepíti a SIS szűrőmeghajtót, és létrehoz egy 
könyvtárat a WindirtNSystem32 Reminst könyvtár alá, amely 
a Risetup.exe futásához szükséges állományokat tartalmaz- 
za. Ha RIS-t a Telepítő futtatása után adtuk hozzá, újra kell 
indítanunk a gépet a SIS NTFS szűrő telepítéséhez. 


A Risetup.exe futtatása 

Az előzőekben telepített RIS kiszolgáló még korántsem 

működőképes: még egy rakás beállítás hátra van. Ebben 

segít a risetup.exe 

A Risetup.exe fájlt kétféleképpen lehet futtatni: 

"2 A Configure Your Server képernyőről, amikor a számítógép 
a telepítés után újraindul (lásd az előző bekezdésben). 

2 A Start menüben a RUN (futtatás) menüpontra kattintva 
írjuk be, hogy risetup.exe, majd kattintsunk az OK gombra. 

A Risetup.exe indítása után számos párbeszédablakkal ta- 

lálkozunk. Az első (lásd alább) egy üdvözlő képernyő, 

amely a RIS számára szükséges összetevőket sorolja fel. 


Remote Installation Services Setup Wizard! [e] 


Welcome to the Remote 
Installation Services Setup 
Wizard 


This wizard helps you 10 ptepare this server to rettotely 

instal Windows 2000 Professional on remote boot-enabled 

computers 

To successlully install and use the remote 

installation services, you will need: 

- An aclíve DHCP and ONS servet on your nelwotk. 

- A Windows 2000 Professional CD or a shared folder that 
Contans the installation les 


- Client computers that have either a PXE boot ROM or a 
network adapter supported by the boot Iloppy 


To continue, ckck Next 








o A RIS varázslója 


A következő párbeszédablakban (lásd alább) azt a könyvtá- 
rat kell megadnunk, amelyben a RIS az ügyfelek telepítésé- 
hez szükséges telepítőkészleteket - image-nek is hívják - tá- 
rolni fogja. A Risetup automatikusan megkeresi az első olyan 
NTFS kötetet, amely nem rendszerindító. Bármely NTÉS köte- 
tet ki lehet választani, amely nem tartalmazza a rendszer in- 
dításához szükséges fájlokat (Boot.ini, Windir könyvtár). 

A könyvtár neve csak ,alacsony" ASCII karaktereket tartal- 
mazhat. A könyvtár lehet csatolt (mount) köteten, feltéve, 
hogy az NTFS formátumú, és nem rendszerkötet. 
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Remote Installation Services Setup Wizard E] 


Remote Installation Folder Location 
Specily the location for the remote installation foldet. 





Enter the location in which to create the installation folder structure. The diive cannot 
bethe system díive. 

The remote installation server should have enough dízk space to support mulüple 
installation images. The folder structure must be installed on a dííve that is formatted 
with NTFS version 5 or latet. 


Path 


JENEEEEEET TT Biome. 


ét 
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Remote Installation Services Setup Wizard b] 





Windows Installation Image Folder Name 
Piovide a name for lhe Windovs installation image foldet. 


Type a name for the folder to which the Windows files will be copied on this remote 
installation server. 


Foldet name: 





c Back Cancel 





5 A reminst megosztás helye a háttértáron 

A következő képernyőn (lásd alább) megadhatjuk, hogy a kiszol- 
gálónk válaszoljon-e a hozzá érkező kérésekre. Korlátozhatjuk a 
válaszokat a PXE-képes ügyfelekre vagy csak azokra, amelyeket 
előre létrehoztuk a CAO-t az Active Directoryban. 
Használhatjuk ezt a beállítást például akkor, ha azt szeretnénk, 
hogy kiszolgálónk csak az ismert ügyfeleknek válaszoljon. Is- 
mert ügyfél az a számítógép, amelynek van saját CAO-ja az 
Active Directory-ban. Amikor a PXE ügyfél kapcsolatba lép a RIS 
kiszolgálóval, elküldi a GUID-jét (egyedi azonosító, hasonló a 
Media Access Control (MAC) címhez), amelyet össze kell hason- 
lítani a CAO-val, hogy egyezik-e. Biztonságos környezetben ez 
hasznos (nem tud akármelyik ügyfél telepíteni) és egyúttal ter- 
helésmegosztásra is lehetőséget teremt a szervezet RIS kiszol- 
gálói között. Akkor is hasznos, ha más távoli telepítő szolgál- 
tatás is működik a szervezeten belül. 

Ezek a beállítások csak a RIS kiszolgáló és az ügyfél közöt- 
ti DHCP párbeszédre vonatkoznak. Ha a RIS ügyfél a RIS ki- 
szolgáló IP címét mástól tudta meg (például egy hivatkozó 
RIS kiszolgálótól), és az ügyfél erről a kiszolgálóról kíván 
rendszert tölteni, azt is megteheti. 






initial Remote installation Server Settings 
Configure whether this remote installation server wil service cfents at he end of ma) 
setup. 


By defauk, this remote installatlon server wil not service chent computers at the end 
of setup, IF this server should begin servicing cent computers at the end of setup, 
set the appropriate settings below. 


Client servicing 





Cick Next to continue. 


o ARIS szolgáltatás beélesítése 





A következő párbeszédablakban (lásd alább) azt a könyvtá- 
rat kell megadnunk, ahova a munkaállomások telepítéséhez 
szükséges állományok kerülnek majd. A könyvtár neve csak 
betűket és számokat tartalmazhat, szóközök vagy nem 
ASCII karakterek nem lehetnek benne, és a könyvtár neve 
legfeljebb 39 karakterből állhat. 
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5 Az 1386 könyvtár ide kerül a CD-ről 

A következő párbeszédablakban (lásd alább) a CIW leendő 
felhasználói számára magyarázó szöveget adhatunk meg az 
operációs rendszer választásához. Testreszabott Help Desk 
információkat is beírhatunk. Ez az információ a telepítő- 
készlet Templates alkönyvtárában található Rstndrd.sif állo- 
mány [Oschooser] szakaszába kerül. 

Ha ezzel a képernyővel végeztünk, meg kell adnunk a tele- 


pítési médiát 





Remote Installation Services Setup Wizard 


Friendly Description and Help Text 
Provide a friendly description and help text for this installation image. 


Type a friendly description and help text for this Windows installation image. This text 
helps users of the Client Installation wizard choose the correct installation image. 


Friendly desciiptiorc 





Help text 


Automatically installs windows 2000 Professional on the computer without prompting 
the user for input. 


cBack Cancel 
a Az alapértelmezett telepítőkészlet adatai 


Ezek után a Risetup.exe a következőkkel fejezi be a telepí- 

tést: 

"B Létrehozza a könyvtárstruktúrát 

- Bemásolja a Windows 2000 Professional telepítéséhez 
szükséges fájlokat - gyakorlatilag az egész 1386 könyv- 
tárat. 

8 Bemásolja az Ügyféltelepítő varázsló (Client Installation 
Wizard, CIW) képernyőit. 

-? Beállítja a RIS szolgáltatásokat. 

0 Elindítja a RIS számára szükséges szolgáltatásokat (BINL, 
TFTP, és a SIS Groveler szolgáltatás) . 

8 Reminist névvel megosztja a RIS könyvtárstruktúra fő- 
könyvtárát. 

8 Az Active Directoryban létrehozza a megfelelő 

IntelliMirror management technologies Service Control 

Point (SCP) objektumot 

Létrehozza a SIS Common Store könyvtárat és azokat a 

fájlokat, amelyek szükségesek a SIS működéséhez ezen 

a köteten. 
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Ezen a ponton a RIS kiszolgáló telepítése befejeződött, a 
Windows 2000 Professional alapértelmezett beállításokkal 
telepíthető a munkaállomásokra. Már csak hitelesíteni kell 
a kiszolgálót, hogy megkezdhesse az ügyfelek kiszolgálását. 


A RIS kiszolgáló hitelesítése 

Mielőtt a RIS megkezdhetné az ügyfelek kiszolgálását, hi- 
telesíteni kell őt az Active Directory-ban. Ez megakadá- 
lyozza azt, hogy valaki kalóz RIS kiszolgálót indítson el a 
hálózaton, amely értelmezhetné az ügyfelek kéréseit. Saj- 
na ez azonban csak a RIS kiszolgáló és a RIS ügyfél közöt- 
ti DHCP párbeszédre vonatkozik. Ha az ügyfél egy nem hi- 
telesített RIS kiszolgálóra hivatkozik, akkor az is gyönyö- 
rűen telepíteni fogja az operációs rendszert. Ahhoz, hogy 
hitelesítsük a RIS kiszolgálót az Active Directory-ban, 
használjuk a Microsoft Management Console (MMC) DHCP 
snap-injét bármelyik DHCP kiszolgálón, ami ugyanebben az 
Active Directoryban van, és adjuk hozzá, mint meghatal- 
mazott kiszolgálót. Miután hozzáadtuk, ellenőrizzük a RIS 
eseménynaplóját. Ebben a BINLSVC-től (az a szolgáltatás, 
amelyet a RIS az ügyfélszámítógépekkel való kapcsolattar- 
tásra használ) származó eseménynek kell lennie, mely sze- 
rint a kiszolgáló hitelesítetté vált. 

Nem mindig kell hitelesítenünk, hogy a RIS dolgozhasson. 
Ha a kiszolgáló, amelyre a RIS-t telepítjük, már futtatja a 
Windows 2000 DHCP szolgáltatását és az aktív, akkor a 
meghatalmazás automatikusan megtörténik. 

Vagy ha mondjuk van egy Windows NT 4.0 futó DHCP ki- 
szolgálónk, a RIS miatt nem kell Windows 2000 DHCP-t 
beállítanunk, ettől még hitelesíteni tudjuk az Active 
Directory-ban. Lássuk hogyan! 

Tehát ha a kiszolgálón nem fut a Windows 2000 DHCP szol- 
gáltatás, telepítenünk kell az ,Administrative tools"-t, 
hogy hozzáférhessünk a DHCP MMC snap-inhez, mellyel 
végrehajthatjuk a szükséges lépéseket. Az , Administrative 
tools" telepítéséhez egy Windows 2000 Servert vagy Win- 
dows 2000 Professionalt futtató számítógépen indítsuk el 
az adminpak.msi-t a Windows 2000 Server CD-ROM-ról. 
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Csak az , Enterprise Administrators" csoport tagjainak van 

joguk a RIS kiszolgálók meghatalmazására. Ha más fel- 

használóknak vagy csoportoknak is meg kívánjuk adni ezt 

a jogot, az alábbiak szerint járjunk el: 

1. Indítsuk el az Active Directory Sites and Servicest 

2. Az MMC konzol View menüjében kattintsunk a Show 
Services Node pontra 

3. Bontsuk ki a Service kulcsot, majd keressük meg a Net- 
Services kulcsot 

4. Kattintsunk rá a jobb egérgombbal, és válasszuk a 
Properties menüpontot 

5. A Security keretben engedélyezzük a Read, Write, és a 
Create ALI Child Objects jogokat a megfelelő felhaszná- 
ló vagy csoport számára 

6. Kattintsunk az Advanced-re 

7. Az Access control Settings for NetServices párbeszéd- 
ablakban kattintsunk az éppen hozzáadott felhasználó- 
ra vagy csoportra 

8. A View menüben válasszuk az Edit menüpontot 

9. Az Apply onto keretben kattintsunk a This object and 
All Child Objects-re. 

Ha nem akarjuk telepíteni az , Administrative tools"7-t a 

számítógépen, hanem csak a DHCP Manager MMC snap-int, 

akkor az alábbiak szerint járjunk el: 

1. Bontsuk ki a Dhcpsnap.dl fájlt a kiszolgáló CD-jéről a 
WindirtSystem32 könyvtárba 

2. Bontsuk ki a Dhcpmgmt.ms fájlt a kiszolgáló CD-jéről 
a WindirtSystem32 könyvtárba 

3. Futtassuk a "osystemroot9olsystem32 vregsvr32 
dhcpsnap.dll parancsot 

4. Futtassuk a dncpmgmt.msc állományt. 

Miután végrehajtottuk ezeket a lépéseket, futtathatjuk a 

snap-int és meghatalmazhatjuk a kiszolgálót, amennyiben 

megvan a szükséges jogosultságunk. Ha egyéb eszközöket 

(például az Active Directory Users and Computers MMC snap- 

int) is szeretnénk használni, akkor telepítenünk kell az 

Administrative Tools"-t. 

Egyelőre ennyit e végtelen történetről, folyt. köv. 


Dorner Csilla 
dorner.csillaohms.hu 
MCSE 
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eXPressz: újítások a 
. Windows XP Kernelben 


Az elmúlt hetekben többször bemutattuk már a Windows XP 
komolyabb vagy kevésbé komolyabb újításait. Most ezt a 
sorozatot folytatjuk, ezúttal közel a tűzhöz: lássuk, milyen 
teljesítménynövelő újítások vannak az operációs rendszer 
magjában, a Windows XP Kernelben! 


Gyorsabb rendszerindítás 

A felmérések szerint a felhasználók többsége azt szeretné, ha 
az operációs rendszer az eddiginél sokkal hamarabb lenne 
munkára kész, hidegindítás, hibernálás, vagy stand by mód 
után egyaránt. A nem titkolt cél [4] az volt, hogy egy átla- 
gos felhasználó gépén a bekapcsoló gomb megnyomásától a 
használható állapotig legfeljebb fél perc teljen el: 


LO t ee LAT GT AR 








Hidegindítás esetén 30 mp 
Hibernálás után 20 mp 
Stand By állapotból 5 mp 


Ezt az időt persze erősen befolyásolja a hardverek sebessé- 
ge is, ezért a Windows XP fejlesztésének ebben a szakaszá- 
ban a Microsoft szorosan együttműködött az egyes hardver- 
gyártókkal. A legelső dolog a számítógép életében a BIOS - 
éppen ezért ahol lehet, még a BIOS-on is gyorsítottak. 


A Simple Boot Flag 

A számítógép indulásakor futó BIOS POST (Power-On Self 
Test) rutin, a memória ellenőrzése, a lemezek felpörgetése, a 
flopimeghajtó ellenőrzése, a gép gyártója által esetleg meg- 
jelenített logók, a videokártya esetleges logója, valamint az 
egyéb diagnosztikai eljárások sokszor már önmagukban meg- 
haladják az előírt 30 másodpercet. Éppen ezért találták ki a 
Simple Boot Flag nevű CMOS BIOS regisztert, amit az operá- 
ciós rendszer a 0x70-0x71-es porton keresztül ér el. Ezen a 
regiszteren keresztül , beszélgethet" a BIOS és az operációs 
rendszer. Az egyes bitek jelentése a következő: 


A Simple Boot Flag regiszter 














0 PNPOS Plug and Play operációs rendszer 
1 BOOTING Az előző boot sikeres volt 

TA DIAG Diagnosztika futtatása szükséges 
3-6 - Nem használt, értéke 0 

2 PARITY Ellenőrzőbit 


"8 A PNPOS bit 1 értéke azt jelzi, hogy a számítógépen Plug 
8. Play operációs rendszer fut. Ilyenkor a BIOS-nak sem- 
mi dolga a perifériák konfigurálásával, leszámítva persze 
a rendszerindításhoz elengedhetetlenül szükséges eszkö- 
zöket (például a merevlemezt). Ha értéke 0, a BIOS-nak 
kell kiosztania az eszközök részére az erőforrásokat 

2 A BOOTING bit 1 értéke azt jelzi, hogy az előző rendszer- 
indítás sikeres volt, diagnosztikai tesztekre nincs szük- 
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ség. A BIOS ilyenkor a POST futtatása (és további csi- 

csák) helyett azonnal belefog a boot szektor betöltésébe 

A DIAG bit 1 értéke azt jelzi, hogy szükség van a diag- 

nosztika futtatására (ezt beállíthatja az operációs rendszer, 

de maga a BIOS is, ha például a BOOTING bitet 0-nak találta) 

0 A PARITY bit ellenőrzőbit: ha a beállított paritásérték 
nem jó, a regiszter tartalma érvénytelen, teljes rend- 
szerdiagnosztika következik 


Prefecthing 

A Windows XP gyorsaságának lelke az úgynevezett prefecth 
(előtöltés): a rendszer indulásakor naplózza az összes lemezmű- 
veletet. A legközelebbi induláskor pedig az előző naplók alap- 
ján előre, párhuzamos, kötegelt lemezműveletekkel betölti a 
rendszerindítás során szükséges fájlokat, adatokat (eszközmeg- 
hajtók fájljait, a registry részeit, stb.) - még mielőtt a rendszer 
rájönne, hogy szüksége van rá. Amikor pedig kell, rögtön kéz- 
nél (azaz a memóriában) van az adat. A betöltés a , rendes" in- 
dítással párhuzamosan működik, így míg például az eszközmeg- 
hajtók az eszközök felismeréséhez szükséges elkerülhetetlen 
üresjáratukat töltik, a Windows szépen előkészíti a terepet a 
folytatáshoz. A Windows XP emellett a naplók alapján automa- 
tikusan átrendezi a rendszertöltésben résztvevő fájlokat a me- 
revlemezen (így lényegesen megnő az egy műveletben betölthe- 
tő komponensek száma, és persze lecsökken a betöltésükhöz 
szükséges idő). Ennek köszönhetően a boot loader máris négy- 
ötször gyorsabb lesz, mint a Windows 2000-ben. A műveletek- 
hez az XP az előző nyolc rendszerindítás adatait veszi alapul. 
Mindezeken túl a Windows XP optimalizálja az eszközmeghaj- 
tók betöltésének sorrendjét, hogy a felhasználó minél előbb 
hozzájuthasson a bejelentkezőképernyőhöz. Ha például a 
Windows XP nincs tartományban, és a bejelentkezéshez nincs 
szükség a hálózati komponensekre, azok indítása időben hát- 
rébb csúszik (a Winlogon tehát nem vár többé a hálózat elin- 
dítására!). Sok eszközmeghajtó már nem sorban, egymást 
megvárva, hanem egymással párhuzamosan indulhat el. 
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5 A bootvis.exe sok mindent elárul a rendszerindítási 
folyamatról 


tech.net 


WINDows 2000 


A Windows XP rendszerindításának folyamatát figyelemmel 
kísérhetjük a [4] címről letölthető bootvis.exe nevű esz- 
közzel, amellyel nem csak a különféle indulási idők, de a 
lemezműveletek, a processzor terheltsége, a ,lusta" esz- 
közmeghajtók is megfigyelhetők, sőt, a bootvis.exe képes 
a bootkörnyezet - már leírt, egyébként előbb-utóbb auto- 
matikusan is végbemenő - optimalizálására is. Az optima- 
lizálás után a tesztgépünkön futó Windows XP teljes indu- 
lási ideje 279o-kal csökkent (az ábrán látható 36 másodperc 
egy átlagos indulási idő, P450 processzoron, UDMA-66-os 
merevlemezekkel, 512MB RAM-mal). 


Prefetching az alkalmazásoknál 

Ezúttal tényleg igaz a marketingfogás: a Windows XP tény- 
leg gyorsabban futtatja az alkalmazásokat! A prefecthing 
algoritmus ugyanis nemcsak az operációs rendszer indítá- 
sakor, de - az XP Server verzióinak kivételével, illetve, ha- 
csak kifejezetten le nem tiltjuk - minden egyes alkalmazás 
esetén is működik. Nézzünk csak bele a Windows XP MWin- 
dowstPreFetch könyvtárába! Jónéhány .pf kiterjesztésű 
fájlt találunk majd benne (és egy layout.ini-t, de erről ké- 
sőbb lesz szó). Az egyes prefetch fájlok tartalmazzák az al- 
kalmazások futása során használt lemezterületek adatait 
(fájlokat, .dil-eket, registry kulcsot, satöbbi). Ha egy alkal- 
mazáshoz már létezik prefetch fájl, a Windows XP az alkal- 
mazás indításakor automatikusan betölti a szükséges ada- 
tokat, hogy mire az alkalmazásnak szüksége lesz rá, kéznél 
legyen. (A rendszerindítás prefetch fájlja az notosboot- 
BOODFAAD.pf; ez a fájl tartalmazza az előző nyolc rend- 
szerindítás adatait. Ez a fájl a rendszerindítás után 1 perc- 
cel jön létre, illetve frissül. (Ha letöröljük, a következő 
rendszerindításnál nem lesz prefetch - ideális eszköz a 
prefetch hasznosságának kipróbálására) . 


Egy fontos dolgot jegyezzünk meg: a prefecth akkor 
képes igazán jól működni, ha van hova betölteni az 
adatokat. Éppen ezért a Windows XP memóriaigényé- 
nek kielégítése teljesítményokokból fontosabb, mint 
az elődöké volt. A minimális 128 megabájt a mai me- 
móriaáraknál már nem okozhat gondot. 


A lemezterület automatikus optimalizálása 

A prefetch jó és gyors működésének fontos feltétele, hogy 
a betöltendő adatok a lemezen is megfelelő sorrendben le- 
gyenek. Mit sem ér a prefetch algoritmus, ha a gyors be- 
töltés során ide-oda kell rángatni a vincseszter fejét! A 
Windows XP ezért a számítógép pihenőidejében (idle álla- 
pot esetén) folyamatosan optimalizálja a merevlemezek 
tartalmát (!). A prefetch szolgáltatás a prefetch fájlokból 
kiolvassa a boot és az alkalmazások indításának adatait, és 
ezek alapján felépíti a layout.inf fájlt. Az automatikus 
defragmentálás ezután ez alapján működik. A layout.inf 
fájl 32 alkalmazás elindítása után jön létre először, és a 
rendszerindítások során automatikusan frissül. 


Hibernálás 

A hibernálás is tartalmaz újításokat: a Windows XP ugyan to- 
vábbra is a fizikai memóriával megegyező méretű fájlt foglal 
le a bootpartíció gyökerében, de ma már szó sincs arról, hogy 
minden egyes bitet a lemezre mentene. A hibernálás előtt az 
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XP felszabadítja a zero, free, standby listában található me- 
mórialapokat, ezek nem kerülnek ki a lemezre. A hibernálás 
során (az adatok lemezre írásával egyébként egyidejűleg) az 
XP még tömöríti is az adatokat. A lemezre írásnál érdemes 
tudni, hogy az XP már DMA-t használ a hibernáláshoz. 

A hibernált gép felélesztése is kicsit másképp működik: a 
bootszektorba ugyanis nem fér bele a lemez eléréséhez és 
kitömörítéséhez szükséges kód, ezért az XP csak a kitömöri- 
téssel foglalkozik, a beolvasást a BIOS funkciókra (!) bízza. 
Ez természetesen lassabb, mintha a saját rutinját használná, 
de a mentéskor alkalmazott adatszűrésnek és tömörítésnek 
köszönhetően ez a lassúság nem számottevő. (A tesztgé- 
pünkben található 384MB RAM-ról hibernált Windows XP 6 (!) 
másodperc alatt éledt fel a teljes fagyhalálból. Ez már megkö- 
Zelíti a stand by értéket — az is igaz, hogy a 384 MB memó- 
riának csak nagyon kis hányadát használtuk valójában). 


A Registry 

A Registry statikus konfigurációs adatbázis, amely a számí- 
tógép, illetve a szoftverek különféle beállításait tartalmaz- 
za - legalábbis szeretnénk ezt hinni. A legnagyobb téve- 
dés a statikusság: valójában a programok gyakran használ- 
ják a Registry-t (nem feltétlenül szerencsésen) dinamikus, 
gyakran változó adatok tárolására is, pedig eredetileg nem 
arra tervezték. A folyamatos használat során a Registry tö- 
redezetté válik, a benne tárolt adatok elérése lassul. A tö- 
redezettség pedig addig nem múlik el, míg azt egy arra al- 
kalmas eszközzel (például a korábban általunk is bemuta- 
tott SysInternals PageDefrag-gal) meg nem gyógyítjuk. 
Amikor egy alkalmazás új kulcso(ka)t hozott létre, a ré- 
gebbi Windows-ok megkeresték az első rendelkezésre álló 
helyet a Registry-ben, és elkezdték a kulcsok létrehozását. 
Ha a hely nem volt elég az összes kulcshoz, az ,összetar- 
tozó" kulcsok a Registry elszórt pontjaira kerültek. Amikor 
az alkalmazás használni kezdte volna ugyanezeket, az ol- 
vasás során újabb és újabb lapokat kellett betölteni, és ez 
természetesen időbe került. 


Windows XP 


Windows 2000 


1. alkalmazás, kulcs 3. 
2. alkalmazás, kulcs 1. 


1. alkalmazás, kulcs 1. 





zás, kulcs 2. 
1. alkalmazás, kulcs 3. 


1. alkalmazás, kulcs 4. 





5. alkalmazás, kulcs 1. 


1. alkalmazás, kulcs 4. 2. alkalmazás, kulcs 1. 





3. alkalmazás, kulcs 2. 2. alkalmazás, kulcs 2. 


2. alkalmazás, kulcs 3. 
4. alkalmazás, kulcs 1. 
4. alkalmazás, kulcs 2. 

6. alkalmazás, kulcs 1. 


3. alkalmazás, kulcs 1. 


3. alkalmazás, kulcs 2. 


2. alkalmazás, kulcs 2. 
4. alkalmazás, kulcs 2. 


3. alkalmazás, kulcs 1. 





fosítatmazás tes 3.) 5 A Windows 
XP már a kul- 
csok létrehozá- 
sakor ügyel a 


töredezettségre 





5. alkalmazás, kulcs 1. 





3. alkalmazás, kulcs 3. 


6. alkalmazás, kulcs 1. 





3. alkalmazás, kulcs 4. 3. alkalmazás, kulcs 4. 




















Amikor a Windows XP létrehozza a kulcsokat, megpróbálja 
megkeresni azt a helyet, ahol az összes kulcs (illetve az 
egyes kulcsokhoz tartozó további adatok, például jogosult- 
ságlista) egymáshoz közel tárolható, így az adatok 
visszaolvasása is sokkal gyorsabb lesz majd. 
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WINDows 2000 ÚJÍT 


A Windows korábbi változataiban a Registry másolata a kernel 
memóriájában tanyázott. Ez (memóriatervezési okokból) legfel- 
jebb körülbelül 160MB méretűre duzzadhat, ezért előfordult, 
hogy egy-egy bonyolultabb, nagyobb Registry a kernel rendel- 
kezésére álló memória nagy részét felemésztette. A Windows 
XP-ben a Registry nem a kernel memóriába töltődik be, így 
többé nem falja fel a memóriát az operációs rendszer elől. En- 
nek viszont ára van: ha a registry nem a kernel memóriában 
van, azt lassabban lehet elérni. Az XP újraírt (és újratervezett) 
Registry-kezelő rutinjai ezért számos trükköt alkalmaznak. 


Kulcskeresés a Windows 2000-ben 





Sokadik alkalommal 


3. alkalmazás ! futó alkalmazás 











ilálála Registry Manager is zül 


Leszel SE z atát 








3 
4 


Tsz] 


1. lépésnél 











Registry 








— 


3. alkalmazás, 
kulcs 1. 


1. kulcs 1 beolvasása 
2. kulcs 1 beolvasása (ismét) 
3. kulcs 5 beolvasása 
( nem létezik) 
4. kulcs 5 beolvasása (ismét) 














Registry Cache 
5 Registry-műveletek a Windows 2000-ben... 


Kulcskeresés a Windows XP-ben 


Sokadik alkalommal 
3. alkalmazás ! futó alkalmazás 
í1[2]13]4 Registry Manager 
Keresésés, ha 


nincs a cache-ben 


ossze 


Kulcsok betöltése 
az alkalmazás 
indításakor 




















Registry 








[2 





1. kulcs 1 beolvasása 
2. kulcs 1 beolvasása (ismét) 
3. kulcs 5 beolvasása 

( nem létezik) 
4. kulcs 5 beolvasása (ismét) 


3. alkalmazás, 
kulcs 1. 








Registry Cache 


5 ... és a Windows XP-ben 


E trükkök egyike az alkalmazáshoz tartozó kulcsok gyorsító- 
tárazása. A registry-gyorsítótárat már a korábbi Windows 
verziók is alkalmazták, de csak a létező kulcsok esetén. Az 
alkalmazások viszont sokszor csak egy-egy kulcs létezését 
ellenőrzik. Amikor az alkalmazás olyan kulcsra hivatkozik, 
ami nincs a gyorsítótárban, a Windows keresni kezdi azt a 
registryben. Mivel a Windows 2000 a nemlétező kulcsokat 
nem tárolta a gyorsítótárban, minden ilyen kulcsra irányu- 
ló kérés a Registry végigpásztázását eredményezte. A Win- 
dows XP tárolja a kulcs nemlétezésére vonatkozó informá- 
ciókat is, sőt, a prefetch műveletek során az alkalmazáshoz 
tartozó, általa használt registry kulcsok már az alkalmazás 
indulásakor betöltődnek a gyorsítótárba, így a Windows XP 
már az első kérést is onnan szolgálja ki. 

Még egy kellemes újdonság a témával kapcsolatban: megszűnt 
végre a Registry Editor (regedit) zavaró skizofréniája. A Win- 
dows XP-ben található eszköz az eredeti regedit.exe-hez ha- 
sonlít (azaz nem többablakos) , viszont mindent tud: kezeli a 
kulcsok jogosultságait, felismeri a többsoros szöveges értéke- 
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ket. Kompatibilitási okokból a regedt32.exe is megmaradt, de 
nem csinál mást, mint hogy elindítja a regedit.exe-t. 


Hibakeresés 

A Windows XP új hibakereső eszközöket (debuggereket) tar- 

talmaz. Az eszközök között megtaláljuk a WinDbg, KD, CDB 

újraírt verzióit, sőt, ezek 64 bites változatát is. Az új 
debuggerek használhatók a Windows NT 4.0 és a Windows 

2000 rendszerekkel is, bár néhány funkció értelemszerűen 

csak a Windows XP-ben használható. Az eszközökről 

széleskörű információ a [2] címen található. 

Néhány újdonság: 

6 Cross-Session Debugging: a régebbi debuggerek a Windows 

Session Manageren (csrss.exe) keresztül működtek. Ez 

gondot okozott a Terminal Services használatakor, hi- 

szen akkor minden felhasználó saját Win32 alrendszerét 

futtatja, saját csrss példánnyal. Így természetesen a 

terminálok közötti hibakeresés nem működött - a Win- 

dows XP-ben már igen. 

Ouit and Detach: Kilépés és lecsatlakozás. A Windows XP 

Kernel Debugger új parancsa (gd) lehetővé teszi, hogy 

a debuggerből való kilépéskor a felügyelt alkalmazás ne 

álljon le. Ha a gd paranccsal hagyjuk el a debuggert, az 

alkalmazás tovább futhat. 

"0 IEEE 1384: Az új debugger képes a soros port helyett 
FireWire (IEEE 1384) csatlakozón keresztül működni (a 
Windows Me esetén ez már most is működik). Egy IEEE 
1384 buszra a debugger gép mellé akár 62 másik számí- 
tógép csatlakoztatható. 


b 


multi(O)disk(O)rdisk(O)partition( 1) IWINDOWS-Z 
Hu "Microsoft Windows XP Professional" /debug 


§  /debugport-1384 /channel-1 


5 Ha a boot.ini /debugport kapcsolójának a 1384 érté- 
ket adjuk, a debugger az IEEE 1384-et használja 


"2 Debug-child: A debugger által , betöltött" processz beál- 
lítható jellemzője, hogy csak őt, vagy az általa indított 
processzeket is szeretnénk-e debuggolni. A Windows XP 
előtt ez a beállítás a processz indításakor eldőlt, később 
nem lehetett változtatni - ma már lehet. 

I Gyorsabb soros port-használat: a lassú, soros porton ke- 
resztüli hibakeresés esetén jól jön, hogy a Windows XP 
debugger hatékonyabban használja a rendelkezésre álló 
kapcsolatot 

"8 Eszközmeghajtó feltöltés a Kernel Debuggeren keresztül: 
amikor a Windows XP egy eszközmeghajtót készül indí- 
tani, lekérdezi a debuggert, hogy rendelkezik-e újabb, 
jobb eszközmeghajtóval. Ezzel megspórolható az esz- 
közmeghajtó-telepítéshez szükséges újraindítás. 


Harc a memóriafolyás ellen 

A feladat elkapni a memóriát lefoglaló, de azt fel nem sza- 
badító alkalmazások grabancát. A Windows XP két fronton 
veszi fel a harcot: 

I Memóriafolyás felismerése a processz befejezésekor: ha a 
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WINDOows 2000 


HKEY LOCAL MACHINENSOFTWARElMMicrosoftlWindows NTV 
4 CurrentVersionlImage File Execution Options) 


4 cimagenamesz shutdownFlags 


DWORD értéket 3-ra állítjuk (az cimagenamez: helyére írjuk 
a felügyelendő alkalmazás nevét, pl. notepad.exe), a Win- 
dows XP a program kilépésekor a körmére néz, és ha felsza- 
badítatlan memóriaterületet talál, riasztja a felhasználót: 


ar lax 
FocalülloetLPIR, 19983 3 B-00233349 2 
LocalálloccLPTRI ; 

LocalálloccLPIR; 19895 
LocalállocéLPTR 

LocalálloccCLPTR: 






fe eseegdon reboot 
Alredpori 
tarándoont) a 





I 
the apelestan at location a09f7ÉS7N. 








Clekenoktotemaste the program 
[ 











FseslnllocéketRI 10805 -5 0.46 I) 
5 A Windows XP elkapja a memóriapocsékoló alkalma- 
zások grabancát 


Szerencsére (?) azért nem mindig olyan súlyos a helyzet, 
mint amit a fenti ábrán a [3] címről letölthető példaprog- 
rammal előállítottunk.... 

"01 Heap számlálók a Performance Monitorban: ha a 


HKEY LOCAL MACHINENSYSTEM(CurrentControlsSett 
4 ServiceslPerfProciPerformanceN 


u, DisplayHeapPerfoObject 


DWORD értéket 1-re állítjuk, a Performance Monitor-ban 
több mint 20 új számláló jelenik meg. 


A prefetch kikapcsolható 

Érdemes tudni, hogy a prefetching műveletet az új Logical 
Prefetcher rendszerszolgáltatás, míg a futás közbeni nap- 
lók feldolgozását, és prefetch-fájlba írását a Task 
Scheduler (!) végzi. Amiért érdekes, (és amiért pont a me- 
móriamenedzsment címszó alatt említjük meg), az a pre- 
fetch letilthatóságának helye a Registry-ben: 


HKEY LOCAL MACHINENSYSTEMÍCurrentControlSett 
", ControllSession ManageriMemory Management) 


W PrefetchParameters) 


A fenti kulcs alatt található EnablePrefetcher DWORD érték ha- 
tározza meg, hogy a prefecthing működjön-e. Az érték 0. bitje 
engedélyezi az alkalmazás, az 1. bit pedig a rendszertöltés 
gyorsítását (ha tehát a fenti értéknek 3-at adunk meg, a tel- 
jeskörű prefecthet engedélyezzük) . A Windows XP munkaállomá- 
sokon (Professional, Home Edition) ez az érték 3 (azaz tel- 
jeskörű) , a Windows .NET Server-eken pedig 2 (azaz csak boot). 





ÚJÍTÁSOK A WINDOWS XP KERNELBEN 


A WebDAV File System Driver 

A File System Driver-ek feladata, hogy a Windows fájlrend- 
szerébe integráljanak eredetileg nem ott található tároló- 
kat. Ilyen FSD például a Windows hálózati meghajtókat ke- 
zelő komponense (a , Map Network Drive") is. A Windows 
XP-ben egy új File System Driver-rel találkozhatunk, amely 
a WebDAV File System Driver névre hallgat. 


Windovis can help you connect to a shared network folder 
and assign a drive letter to the connection so that you can 
access the folder using My Computer. 


Specify the drive letter for the connection and the folder 
that you want to connect tor 


Drive: TT: v 


Folder:  http://webdav.netacaden s ( Browse... 


Example: tiservertshare 
E geconnect at logon 
Connect using a different user name. 


San up storage or connect to a 


tear] 


0 Munkában a WebDAV File System Driver 


Az új FSD lehetővé teszi, hogy távoli kiszolgálók WebDAV 
mappáit beépítsük a Windows fájlrendszerébe, ugyanúgy, 
mintha hagyományos Windows megosztott mappákhoz 
csatlakoznánk. (A WebDAV protokollról szeptemberi szá- 
munkban olvashatnak részletesen). A WebDAV FSD gyer- 
megbetegsége, hogy nem képes https:// mappákhoz csat- 
lakozni - ezeket továbbra is csak (például a My Network 
Places-ből elérhető) webmappaként használhatjuk. 


Még néhány szó a defragmentálásról 

A beépített töredezettségmentesítő előnyeit a Windows 

2000 óta élvezhetjük. Az XP defragmenter programozói fe- 

lülete (ezzel együtt majd nyilván a ráépülő alkalmazások 

többsége is) tartalmaz néhány újdonságot: 

0 Alapvető változás, hogy a defragmentálás ezentúl nem a 
System Cache-en keresztül történik (egy átlagos fel- 
használónak ez annyit jelent, hogy a töredezettségmen- 
tesítés során ezentúl a fájlok nem lesznek olvasásra 
megnyitva) 

"8 Az MFT (Master File Table) is defragmentálható 

Defragmentálható lett az NTFS fájlok attribútuma, az 

indexek, valamint a bitmap fájl is. 


5) 


Fülöp Miklós 
mick Enetacademia.net 


esett rag AL TT 


[1] http://msdn.microsoft.com/library/en-us/appendix/enhancements5 9b74.asp 
[2] http://www.microsoft.com/ddk/debugging/ 

[3] http://technet.netacademia.net/download/leak 

[4] http://www.microsoft.com/hwdev/fastboot/ 
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SZERSZÁMOSLÁDA 


Az elmúlt hetekben (főleg az új internetes férgeknek — Code 
Red, Nimda és társai - köszönhetően) megszaporodtak a 
Windows webkiszolgálók elleni támadások. Ma már nem 
elég az hinni, hogy az Internet valamelyik sarkában el tu- 
dunk bújni, a férgek szisztematikusan támadnak: végigpró- 
bálnak minden címet, idejükből kitelik. Egyetlen esélyünk a 
védekezés. Cikkünkben bemutatunk két új eszközt az IIS 
biztonságának növelésére, valamint másik két eszközt, 
melynek segítségével a gyorsjavítások ellenőrzését és tele- 
pítését könnyíthetjük meg (ezek az utóbbi eszközök nem- 
csak a webkiszolgálóként működő gépeken, de minden Win- 
dows NT-n és Windows 2000-n használhatók). 


IISLockD - IIS Lockdown Tool 

Az eszköz neve máris félreértésre adhat okot, ugyanis az IIS 

védelméről szól, holott az eszköz csak a webkiszolgáló biz- 

tonsági beállításaira használható. Ne feledjük el, hogy az 

IIS-nek a webkiszolgálón kívül része az FTP, az SMTP és az 

NNTP kiszolgáló is (különösen tartsuk ezt a fejünkben, amikor 

a gyorsjavításokat telepítjük). Az IISLockD letöltése [1] és 

telepítése után a könyvtárban három fájlt találunk: magát az 

eszközt, a hozzá tartozó help fájlt, valamint egy 404.dll-t. Ez 
utóbbi különös fontosságú lesz a későbbiek során. 

Legyünk óvatosak! Az eszköz nagyon szigorú, felkészületlenül 

használva könnyen üzemen kívül helyezhetjük az IIS-ünket. 

Szerencsére ha kell, visszaállíthatjuk az eredeti állapotot az 

Undo parancs használatával. De lássuk, mit is tud az IISLockD! 

Az IISLockD varázsló Windows NT 4.0 (IIS 4.0) és Windows 

2000 (IIS 5.0) esetén is használható. Indulásakor két kon- 

figurációt ajánl fel: 

"8 Express Lockdown - automatikus konfigurálás, statikus 
webkiszolgálók részére. Vigyázat! Minden dinamikus 
szolgáltatást letilt (az ASP-t is)! 

b Advanced Lockdown - testreszabható beállítások 

A testreszabható beállítások között pedig az alábbiakat találjuk: 

8 Az ASP oldalak letiltása - tiltsuk le, ha nincs szükség 
dinamikusan generált tartalomra (.asp, .asa, .cer, .cdx) 

B Az Index Server webes interfészének letiltása - ehelyett 
már régóta a programozható scriptfelületét használjuk 
(.ida, .htw, .ida) . Ez a komponens sok IIS hiba forrása volt 

0 A Server Side Includes letiltása - Tiltsuk le, hacsak nem 
használjuk (.shtml, .shtm, .stm) 

"8 Az lwnternet Data Connector letiltása - Ezer éve nem hasz- 
nált webes adatbázisinterfész, emellett sok-sok bizton- 
sági rés melegágya (képzavar - a szerk.) (.idc) 

"8 Az Internetes nyomtatás letiltása - Tiltsuk le, hacsak 
nem használjuk (.printer) 

"A .htr scriptek letiltása - Lásd mint az előző (.htr) 

Akinek ezek a lépések ismerősek, nem téved: a legtöbb biz- 

tonsági ajánlásban szerepel ezek eltávolítása. Ha viszont 

egyszerűen töröljük a hozzárendelést, előfordulhat, hogy az 
adott komponens újratelepítése, vagy egy javítócsomag 
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Golyóálló IIS 


esetén a hozzárendelés újra megjelenik. Az IISLockD azon- 
ban ennél sokkal trükkösebb: 


























o A letiltott kiterjesztések valójában nem tiltódnak le... 


Az IISLockD futása során a könyvtárában található 404.dil 
fájlt telepíti a NSystem32Nnetsrv könyvtárba, majd minden 
ntiltott" kérést ráirányít. Ezután minden ilyen kérés a kö- 
vetkező választ kapja (egyébként szabványos, de rövid HTTP 
hibaüzenet formájában): 





Záhttp://localhost/1.htw- Microsoft internet Expiőreti 


File Edit View  Favorites Tools Help 
r-s -AODAláaHGZH4]B AE 
Address [8] http://focalhost/1.htw 


Object Disabled 
5 ,.. hanem diszkrét hibát adnak vissza 


Ennek a megoldásnak két előnye van: egyrészt, a rövid (ke- 
vesebb, mint kétszáz bájtos) hibaüzenet a minket ért táma- 
dás során nem terheli annyira a vonalunkat, mint az 
alapértelmezett, több (kb. négy) kilobájtnyi színes-szagos 
üzenet; a másik, hogy - miután a scripthozzárendeléseket 
nem töröltük - azok nem fognak a későbbiekben ,véletle- 
nül" újra létrejönni, és lyukat ütni a rendszerbe. 


Az IISLockD varázsló további beállításai: 

0 A példaként telepített webfájlok törlése (ez az IISSamples 
virtuális könyvtár törlését jelenti, az eredeti fájlok a leme- 
Zen (az Ninetpub Niissamples könyvtárban) megmaradnak, de 
nem lesznek elérhetők) - ebben a könyvtárban néhány hi- 
bás példakódnak köszönhetően jópár veszélyes lyuk lakik. 

0 A Scripts virtuális könyvtár törlése - alapértelmezett, 
futtatási joggal felruházott könyvtár. Ha a támadó va- 
lamilyen más módon e könyvtár alá bármit be tud töl- 
teni, azt , kívülről" már gyerekjáték futtatni. E könyvtár 
tartalma is megmarad, csak a virtuális hozzárendelés 
szűnik meg. Ha a gépen Proxy Server 2.0 fut, még a vir- 
tuális könyvtárat se töröljük, mert a Proxy Server 
azután nem fog működni. 

-8 Az MSADC virtuális könyvtár törlése - az MSADC adat- 
báziskomponens telepítője által létrehozott virtuális 
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mappa, sokszor hibás, biztonsági rést okozó példakódok- 
kal. Hacsak nincs rá kifejezetten szükségünk, töröljük ki. 
A WebDAV letiltása — a WebDAV HTTP protokollon keresz- 
tül megvalósított, írásra és olvasásra egyaránt használ- 
ható protokoll, melyről korábbi számunkban már ír- 
tunk. Ha nem használjuk, itt letilthatjuk, de vigyáz- 
zunk, mert a WebDAV globális letiltásának egyetlen 
módja, ha a httpext.dll-hez megszüntetjük a System 
felhasználó hozzáférési jogait. Az IISLockD is ezt teszi. 


b 


javítócsomagok sem lesznek képesek frissíteni ezt a 
komponenst (tehát javítócsomag, hotfix telepítése előtt 
Az IISLockD két új csoportot hoz létre: ezek a Web 
Anonymous Users (tagja az IUSR agépnév: felhasználó) és 
a Web Application (tagja az INAM zgépnév:). Az NTFS jo- 
gosultságokat ezután ezeknek a csoportoknak osztja ki, és 
ezentúl tegyünk így mi is. 
0 Az TIS anonymous felhasználó rendszereszközökhöz való 
hozzáféréseinek letiltása - ha kiválasztjuk, az IISLockD 
a fontos rendszerkomponensekhez a fenti csoportok- 
nak explicit tilt minden hozzáférést (Full Control Deny 
jogosultságot állít be). 
webkiszolgáló tartalmához - ha ezt választjuk az 
IISLockD explicit írás tiltást állít be többek között az 
WnetPublwwwroot könyvtáron. 
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a Explicit tiltó NTFS jogok az IISLockD futása után 


Joggal merülhet fel a kérdés, hogy mi történik akkor, ami- 
kor az IISLockD-t Windows NT 4.0-n használjuk (ott ugyan- 
is a jogosultságlistában nincs tiltó típusú jog)? Nos, az 
eredeti eszközöket használva valóban nincs ilyen, és elő- 
fordulhat, hogy az átállított fájlok jogosultságlistájához az 
IISLockD futtatása során nem fogunk hozzáférni. Az igaz- 
ság azonban az, hogy bár a felhasználói felületre nincs ki- 
vezetve, a Windows NT 4.0 a Service Pack 4 óta a Windows 
2000-kompatíbilis NTFS fájlrendszert használja, ahol pedig 
definiálhatók ilyen jogosultságok. Ezután már csak egy va- 
lami hiányzik: az eszköz, amivel ezeket a beállításokat 
elérhetjük. Kaparjuk csak elő a Windows NT 4.0 Service 
Pack 4 CD-t, és - ha még nem tettük meg - telepítsük az 
MMSSCE könyvtárban található Microsoft Security 
Configuration Editort! Ezután a fájlok tulajdonságlapján a 
fentihez hasonló biztonsági oldalak jelennek majd meg, és 
máris kezelhetjük a Deny jogokat! 
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A műveletekről az IISLockD naplófájlt készít, amiből kiol- 
vashatjuk, mit tett a konfigurálás során (naplófájl: 
ISystem32inetsrv Joblt-log.log; riport: oblt-rep.log). A fut- 
tatás előtt az IISLockD automatikusan elmenti az IIS kon- 


teljeskörű lehet, ha mégis szükség lenne rá. 


Fontos! A drasztikus beállítások és NTFS jogosultsá- 
gok miatt mindenképpen teszteljük a beállításokat 
mielőtt az éles kiszolgálót módosítanánk! 


Az IISLockD és az Exchange Outlook Web Access 

Az Outlook Web Access képes komolyan megsínyleni az 

IISLockD futtatását [2], legyen szó akár az Exchange 

Server 5.5-ről, akár az Exchange 2000-ről. Azért a helyzet 

nem reménytelen. Exchange Server 5.5 esetén a követke- 

zőkre figyeljünk: 

2 Ne tiltsuk le az .asp hozzárendelést 

B Ha a.htr hozzárendelést letiltjuk, csak az Outlook Web 
Access jelszómódosító komponense nem fog működni 

Exchange 2000 esetén: 

"8 Ha az.asp hozzárendelést letiltjuk, a Outlook Web 
Access multimédia gombja nem fog működni 

-? Ha a.htr hozzárendelést letiltjuk, csak az Outlook Web 
Access jelszómódosító komponense nem fog működni 

0 Ne tiltsuk le a WebDAV szolgáltatást 

b Ne engedélyezzük az IIS anonymous felhasználók expli- 
cit írásjogának letiltását a webkiszolgáló tartalmához 
(az Exchange virtuális mappái miatt) 

Ehelyett kézzel, a fáljrendszerben letilthatjuk az összes 

többi mappához való hozzáférést, csak az Exchange virtuá- 

lis mappáit kíméljük meg. 


URLScan - a webkiszolgálóhoz érkező URL-ek ellenőrzése 
Az URLScan [3] egy régóta várt eszköz. Feladata, hogy 
szűrje a webkiszolgálóhoz beérkező kéréseket. Menet köz- 
ben (még mielőtt az IIS nekikezdene a kiszolgáláshoz) nor- 
malizálja a kéréseket, kiszűri belőle a gyanús vagy éppen- 
séggel közismerten veszélyes elemeket. (Ún. ISAPI filter- 
ként működik, ezért képes a beérkező kérések, sőt, akár a ki- 
menő válaszok tartalmának módosítására is.) Az URLScan 
az alábbi feltételeket ellenőrizheti, illetve szűrheti: 

"0 A HTTP kérés parancsát (GET, POST, stb.) 

A kért fájl kiterjesztését 

Az URL kódolás típusát 

A nem-ASCII karaktereket a kérésben 

Adott karaktersorozatot a kérésben 

Adott fejléceket a HTTP kérésben 

Ha az URLScan automatikus telepítését választjuk, az a tel- 
jes webkiszolgálóra érvényes lesz, kiszolgálószintű ISAPI 
filterként jelenik majd meg. (Lásd: Internet Services 
Manager / zgépnév: / Properties / Master Properties: WWW 
Service / Edit... / ISAPI filters fül) 

Ha ezt szeretnénk elkerülni, a telepítőt az urlscan.exe -c 
paranccsal indítsuk, ilyenkor az csak kitömöríti a fájlokat, 
és magunknak kell elvégeznünk az ISAPI filterek telepíté- 
sét. Ennek módját a csomagban található urlscan.txt-ben, 
illetve a [4] címen találjuk. 
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a Az URLScan kiszolgálószintű komponensként települ 


Az alapértelmezett telepítés szigorú beállításai csak a stati- 
kus HTML és az ASP oldalak működését engedélyezik, min- 
den más (WebDAV, FrontPage Server Extension, Index Service, 
CGI programok, SSI, Internet nyomtatás, stb.) tiltott. 


Az URLScan.ini 

Az URLScan működését a Wwinntieystem32Vnetsrvturlscan 

könyvtárban található URLScan.ini fájl segítségével befo- 

lyásolhatjuk. (Ugyanebben a könyvtárban készül egyébként 
az urlscan.log fájl is, ami az aktuálisan érvényes beállításo- 
kat, valamint a visszautasított kéréseket tartalmazó napló.) 

Ahhoz, hogy a változtatások érvényre jussanak, újra kell 

majd indítanunk a webszolgáltatást. Az URLScan.ini tartal- 

ma több fő részre bomlik. Az [Options] rész tartalmazza a 

globális beállításokat, a fontosabbak: 

"0? UseAllowVerbs - HTTP kérések szűrésének módja. Ha érté- 
ke 1, akkor csak az [AllowVerbs] szakaszban felsorolt 
HTTP parancsokat fogadja el; ha értéke 0, akkor viszont 
csak a [DenyVerbs] szakaszban felsorolt HTTP parancso- 
kat utasítja vissza. 

"8 UseAllowExtensions - Kiterjesztések szűrésének módja. 
Ha értéke 1, akkor csak az [AllowExtensions] szakasz- 
ban felsorolt kiterjesztéseket fogadja el, ha pedig 0, 
akkor csak a [DenyExtensions] szakaszban felsorolt ki- 
terjesztéseket utasítja vissza. 

"2 AllowDotlnPath - ha értéke 1, akkor engedélyezzük, hogy 

az URL-ben a kiterjesztésen kívül is legyen pont. Ha 0 

(és ez az alapértelmezés), akkor vigyázzunk arra, hogy 

ne legyenek olyan könyvtárak, illetve fájlnevek a kiszol- 

gálón, amelyek nevükben pontot tartalmaznak (pl. 

/pelda.dir/benne.pont.txt). 

EnableLogging - ha értéke 0, nem készül urlscan.log fájl 

2 RemoveServerHeader - ha értéke 1, az IIS által küldött 
válaszban nem szerepel a webkiszolgáló verziójára utaló sor 
Hogy ez mire jó? Egy távoli webkiszolgáló verzióját a legegy- 
szerűbben úgy deríthetjük ki, ha egy üres kérdést küldünk 
neki, majd megnézzük, hogy a válaszban a Server: HTTP fej- 
léc értéke mi. Egy hagyományos IIS5 esetén az alábbi: 


Server: Microsoft-IIS/5.0 
A fejléc kikapcsolása mellett egy másik lehetőségünk is 


van: ha az [Options] szakaszban az AlternateServerName 
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szakasznak értéket adunk, mi magunk határozhatjuk meg, 
hogy a webkiszolgálónk minek hazudja magát. Az alább lát- 
ható beállítás hatására például az IIS-ünk egyszerre indián- 
nak érzi majd magát (ne felejtsük el a változtatás után a 
webszolgáltatást újraindítani) : 


AlternateServerName-Apache/1.3.20 (Unix) 
4 mod ss1/2.8.4 OpenSSL/0.9.6 mod perl/1.26 


A globális opciók után a felsorolások következnek. Az 
[AllowVerbs] / [DenyVerbs], illetve [AllowExtensions] / 
[DenyExtensions] párosokról már volt szó, ezen kívül a kö- 
vetkezők találhatók az urlscan.ini-ben: 

8 [DenyHeaders)] - Ebben a szakaszban sorolhatjuk fel azon 
HTTP fejlécek nevét, amelyeket szeretnénk a kérésekből 
kiszűrni. 

0 [DenyURLSeguences] - Itt pedig olyan karaktersorozatok 
listája található, amelyeket nem szeretnénk az URL- 
ekben viszontlátni. 


FrontPage Server Extension és WebDAV 

Ha szeretnénk, hogy a FrontPage Server Extensions az 

URLScan telepítése után is működjön, az alábbiakat kell 

tennünk: 

0 Az AllowLateScanning mező értékét állítsuk 1-re. 

8 Az [AllowVerbs] szakaszban engedélyezzük az OPTIONS 
parancsot. 

"0 A webszolgáltatás újraindítása után a korábban már em- 
lített helyen ellenőrizzük, hogy az fpexedll.dll magasab- 
ban áll-e, mint az URLscan. Ha nem, cseréljük meg 
őket, majd indítsuk megint újra a webszolgáltatást. 

Ha pedig a WebDAV szolgáltatást szeretnénk engedélyezni: 

"1 Vegyük fel a WebDAV parancsokat az [AllowVerbs] szakasz- 
ba (OPTIONS, PROPFIND, PROPPATCH, MKCOL, DELETE, 
PUT, MOVE, COPY, LOCK, UNLOCK). 

"0 A [DenyHeaders] szakaszból töröljük a Translate:, If:, 
Lock-Token: sorokat. 

"8 A [DenyExtensions] szakaszból töröljük az olyan kiterjesz- 

téseket, amelyek fel- és letöltését engedélyezni szeretnénk. 

Szükség szerint az AllowDotlnPath opciónak adjunk 1 

értéket. 


b 


Az URLScan és az Exchange Outlook Web Access 

Az Outlook Web Access természetesen az URLScan beállításai- 

ra is kényes [2]. Exchange 5.5 esetén egyszerűbb a helyzet: 

A Állítsuk az UseAllowExtensions értékét 0-ra 

"8 Ha a webes jelszóváltoztatást használni szeretnénk, a 
[DenyExtensions] szakaszból távolítsuk el a .htr sort 

Exchange 2000 esetén kicsit több a teendő: 

8 AllowDotlnPath-1 

"8 Az [AllowVerbs] szakaszba az alábbiakat vegyük fel: 
GET, POST, SEARCH, POLL, PROPFIND, BMOVE, BCOPY, 
SUBSCRIBE, COPY, MOVE, PROPPATCH, BPROPPATCH, 
DELETE, BDELETE, MKCOL, OPTIONS 

8 A [DenyHeaders] szakaszból töröljük a Translate: sort 

"B Ha a cég belső DNS neve tartalmazza a .com karakterso- 
rozatot, a [DenyExtensions] szakaszból töröljük a .com sort 


Ha a naplózás engedélyezve van, az URLScan minden 
visszautasított kérést (és annak okát) lejegyzi az 
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URLScan.log fájlba. Ha nem vagyunk biztosak abban, 
hogy mit kellene engedélyeznünk, próbálkozzunk a 
webkiszolgáló használatával, majd a naplóból nézzük 
ki, mit és milyen okból utasított vissza az URLScan. 


HfNetChk - Network Security Hotfix Checker 

Az eszköz [5] csak angol nyelvű operációs rendszerre telepít- 
hető, és igényli az Internet Explorer legalább 5.01-es verzió- 
ját. A kis parancssori eszköz feladata, hogy ellenőrizze a szá- 
mítógépekre telepített biztonsági javításokat. Jelenleg a kö- 
vetkező szoftverek (hiányzó) hotfixeinek felismerésére képes: 
B Windows NT 4.0 minden verziója, Windows 2000 
Professional, Server, Advanced Server 

Windows XP Home, Professional 

0 Internet Information Server (IIS) 4.0 

0 Internet Information Services (IIS) 5.0 

9 SOL Server 7.0, SOL Server 2000, MSDE 

0 Internet Explorer 5.01 vagy újabb verziója 

A HfNetChk az ellenőrzéshez egy XML fájlt használ, amit ma- 
ga a szoftver telepítőkészlete nem tartalmaz. Hacsak erre 
kapcsolóval külön nem kérjük meg, a HfNetChk minden indí- 
tása után megpróbálja letölteni a legfrissebb változat digitá- 
lisan aláírt telepítőkészletét a Microsofttól. Erről a tényről a 
Windows kis ablakban figyelmeztet is (a frissen letöltött 
,MSSecure XML File" elfogadásához kattintsunk a Yes gomb- 
ra). A jelenlegi (2001 október) adatbázis kitömörítve 858 ki- 
lobájt. Ha ez megvan, a kis eszköz a registry-ben, illetve az 
érintett fájlok verzióinak és ellenőrzőösszegeinek ellenőrzé- 
se után korrekt kis riportot készít az elmaradásokról. 

A HfNetChk szintaxisa és kapcsolói (lásd még 

hfnetchk /? illetve [6]): 


Vé; 


hfnetchk.exe [-h hostname)] [-i ipaddress] 
[-d domainname] [-n] [-r range] [-a action] 


[-t threads] [-o output] [-x datasource] [-z] [-v] 


Vr 


-h: az ellenőrizendő számítógép NetBIOS neve; vesszővel 
elválasztva többet is megadhatunk 


0 -i: az ellenőrizendő számítógép IP címe; vesszővel elvá- 
lasztva többet is megadhatunk 

A -r: az ellenőrizendő IP cím tartomány 
(pl. 192.168.0.1-192.168.255.255) 

-b -d: az adott tartomány minden gépét ellenőrzi 

A -n: az alhálózat minden gépét ellenőrzi 

a 


-a: módosítókapcsolók, a listázandó hotfixek beállítása: 
mi" (telepített); ,m" (hiányzó); ,n" (szükséges); ,b" 
(telepített és hiányzó). Az alapértelmezés az ,n" 

B -t: az ellenőrzéshez igénybe vett végrehajtási szálak 
száma (1..128, alapértelmezés 64) 
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"8 -o: a kívánt kimeneti formátum: , tab": tabulált, , wrap" 
szöveges (az alapértelmezés az utóbbi) 

-x: a XML adatforrás helye. Lehet maga az XML fájl, lehet 
az ezt tartalmazó CAB fájl, vagy URL is. Ha nem adjuk 
meg, megpróbálja a legfrissebb verziót letölteni 

: a registry-ellenőrzés letiltása 

I -v: részletes jelentés bekapcsolása szöveges üzemmódban 
Az eszköz helyi futtatásához nem szükséges, bár javasolt, 
a távoli számítógépek ellenőrzéséhez érthető okokból vi- 
szont elengedhetetlen a rendszergazdai jogosultság. 


-p 





OChain - Sok legyet egy csapásra 

Miután a HfNetChk közölte velünk az elmaradásunkat, el 
kell gondolkodnunk azon, hogyan telepítsük a javításokat. 
A hotfixek telepítésének legutálatosabb és legveszélye- 
sebb része az, hogy (elvileg) minden egyes hotfix telepíté- 
se után újra kell(ene) indítani a számítógépet. Aki próbált 
már egy frissen telepített Windows NT 4.0-t naprakészre 
hozni, az tudja, hogy a közel száz gyorsjavítás telepítése 
és az ugyanennyi újraindítás szinte lehetetlen. 

Miért nem lehet újraindítás nélkül telepíteni a hotfixeket? 
Azért, mert a hotfixek által cserélt fájlok sokszor menet köz- 
ben még használatban vannak, ezért azok igazából nem a hot- 
fix telepítésekor, hanem a gép újraindításakor, egy automatiz- 
musnak köszönhetően cserélődnek le. Ha két vagy több hotfix 
ugyanazt a fájlt módosítja, és a hotfixeket újraindítások nél- 
kül, nem a megfelelő sorrendben telepítjük, a végeredmény a 
teljes sikertől a teljes kudarcig terjedő skálán bárhol lehet. 
Ezt az áldatlan állapotot hivatott megoldani a OChain.exe ne- 
vű kis programocska [7], amely a szó szoros értelmében rendet 
tesz a számítógépen (Windows NT 4.0-tól egészen a Windows XP 
friss verzióiig használható). Ha letöltöttük [8], más dolgunk 
sincs, mint tetszőleges sorrendben (!) telepíteni a gyorsjavítá- 
sokat, majd - fontos - még mielőtt a rendszer újraindítanánk, 
futtassuk a OChain.exe-t. A többit csak bízzuk rá. 

A hotfixek jellemzője, hogy a telepítés után feldobnak egy 
vissza nem vonható ablakot, amelyben a rendszer újraindí- 
tását ajánlják fel. Ezt a hotfixek -z kapcsolójával kerülhet- 
jük el (megadása esetén a hotfix nem akarja majd újraindí- 
tani a gépet). Ha akarjuk, a sok-sok hotfixet egy batch- 
fájlba tehetjük, a végén a gchain.exe-vel. Száz hotfix tele- 
pítése egyetlen kattintással? Kánaán! :-) 


90123450 w2k sp2 x86.exe —z 
9123451 w2k sp2 x86.exe —z 
0123452 w2k sp2 x86.exe —z 


achain.exe 
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A cikkben szereplő URL-ek: 


[1] http://www.microsoft.com/Downloads/Release.asp?ReleaseID-32362 
[2] http://support.microsoft.com/support/kb/articles/0309/5/08.ASP 
[3] http://www.microsoft.com/Downloads/Release.asp?ReleaseID-32571 
[4] http://support.microsoft.com/support/kb/articles/0307/6/08.ASP 
[5] http://www.microsoft.com/downloads/release.asp?releaseid-31154 
[6] http://support.microsoft.com/support/kb/articles/g303/2/15.asp 

[71 http://support.microsoft.com/support/kb/articles/0296/8/61.ASP 
[8] http://www.microsoft.com/downloads/release.asp?ReleaseID-29821 
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Ez a cikk azért született, mert a múltkori hash-fejtegetésem 
kapcsán többen jelezték, hogy nem ártana ennél földhözra- 
gadtabb témakörben is körüljárni a működés módját. A digitá- 
tis aláírásról hamarosan törvényünk lesz, mégis sokan vannak, 
akik nem ismerik e megoldás technikai hátterét, így a műkö- 
dés közben felmerülő hibák elhárításában sem fognak jeles- 
kedni. Ez az írás laza cikksorozatot alkot az előző hash-művel. 


Algoritmusok 

Kezdjük a nyílt kulcsú titkosítás és digitális aláirás során fel- 
használt algoritmusokkal. Titkosítási algoritmusból alapve- 
tően kétfélét ismerünk: a szimmetrikus és az asszimmetrikus 
fajtát. A szimmetrikus, vagy más néven egykulcsú titkosítás 
jellemzője, hogy ugyanaz a kulcs nyitja a ládikát, mint ame- 
lyikkel korábban bezártuk. Szoktam még hívni Sándor Mátyás 
titkosításnak is, mert abban is szerepel szimmetrikus titkosí- 
tás: Sándor Mátyás postagalamb lábára kötözött rejtjelezett 
írás segítségével üzen Raguzába. (A rejtjelező eszköz nem 
más, mint egy - mondjuk 10 x 10-es - négyzetrács, melyen kü- 
lönböző helyen lyukak vannak. A lyukakon át kell írni az üze- 
netet a papírra, s a rács forgatásával fokozatosan válik szabad- 
dá mind a 100 karakter. Ilymódon maximum 100 betűs üzene- 
tek kódolására nyílik lehetőség.) A gonosz Sárkány lelövi a 
galambot, de szerencsére nem jut értékelhető információhoz, 
mivel nem áll rendelkezésére a megfejtéshez szükséges rács 
(a kulcs). A rács nélkül semmire sem megy. (A helyszínt és a 
szereplők nevét teljesen fejből írtam, bárminemű tévedés le- 
hetséges...) Ebben az esetben a titkosírás megfejthetetlensé- 
gét a titkosító kulcs elérhetetlensége garantálja. Ilyen algo- 
ritmus például a jó öreg DES (Digital Encryption Standard). 
Ezek az algoritmusok azonban igen nehézkesen használha- 
tók napjaink hálózatain, mert borszasztó kényelmetlen elő- 
re leosztani a titkosítási kulcsokat. A hálózatot nem hasz- 
nálhatjuk kulcstovábbításra, mert az olyan lenne, mintha 
Sándor Mátyás a galamb bal lábára erősítené a rejtjelezett 
írást, jobb lábára meg a rácsot. 

Ide tessenek lőni... 

Még ha a kulcsok előzetes leosztását technikailag meg is 
oldhatnánk a hálózat kiküszöl sével (például telefonon, 
vagy SMS-ben küldenénk át), újabb, immár áthághatatlan 
problémát jelent az a szomorú tény, hogy sajnos nemcsak 
ismerősöknek szeretnénk titkosított levelet küldeni, hanem 
vadidegeneknek, vagy személytelen szervezeteknek is. Egy 
pályázati anyagot például lehet, hogy olyan címre kell el- 
juttatnunk, amelyről az égvilágon semmit sem tudunk a 
puszta emailcímen kívül. Nincs kinek a fülébe súgni a kul- 
csot. Be kell látnunk, hogy a szimmetrikus titkosítási algo- 
ritmusok megbuknak az Internet próbáján. 





Nem baj, van mááásik! 
A nyílt kulcsú, vagy aszimmetrikus titkosítási algoritmusok 
két kulcsot használnak. Amit az egyik zár, azt a másik nyit- 
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ja és vica versa. Az egyik legismertebb ilyen algoritmus az 
RSA (Rivest, Shamir, Adleman matematikusok nevéből), 
melynek matematikáját a következő számban fogom meg- 
fejteni (már most lehet gondolkodni a nadrág megfelelő fel- 
kötésén). A Research rovatban e hónapban a 45. oldalon 
pedig az elliptikus titkosítás magyarázata olvasható. Az 
RSA nem titok, így működik: 

0 szöveg? mod N-titok, ahol D és N a csukókulcs 

0 titokE mod N- szöveg, ahol E és N a nyitókulcs 

Kész csoda, hogy működik nem? Annyira letisztult, mint az 
E-MC2. Az MD5 hash algoritmushoz képest maga a nirvána. 
A kulcsok tehát csereszabatosak, s ha az egyiket soha nem 
adjuk idegenkézre (ez a privát kulcs) , a másikat akár webla- 
punkra is kitehetjük (ez pedig a publikus). 


Nyílt kulcsú titkosítás - deszkamodell 

Most lássuk a titkosítás elvi menetét nyílt kulcsú algoritmu- 
sunk felhasználásával. Az ábra a könnyű érthetőség ked- 
véért végletekig leegyszerűsíti a folyamatot, a valóság en- 
nél bonyolultabb. A cikk végére a valóságot is belekeverjük 
a folyamatba, egyelőre maradjunk a deszkamodellnél: 


1. Helló, levet szeretnék írni 


2. Íme a titkosító kulcs Bszo 


——- 





3. Megy a levél 





o A nyílt kulcsú titkosítás deszkamodellje 


Első lépésben O a feladó bejelenti a címzettnek, hogy tit- 
kosított üzenetet szeretne küldeni. Erre a címzett elküldi a 
hálózaton keresztül a publikus kulcsát 0, hogy azzal titko- 
sítson a feladó. (Itt jegyzem meg, hogy Hacker Henry termé- 
szetesen lesben állt és a hálóról leszedi magának a publikus 
kulcsot.) A feladó ezután a címzett publikus kulcsának se- 
gítségével titkosítja üzenetét, és eljuttatja a címzetthez 0. 
(Hacker Henry mint mindig, most is éberen figyel, s a titko- 
sított üzenetet is elkapja.) A címzett fogja a titkosított üze- 
netet, kibontja a privát kulcsával, és boldogan elolvassa. És 
Hacker Henry? Nála van a titkosított üzenet, és a publikus 
kulcs, mellyel a titkosítás készült. Amit a publikus kulcs 
zárt be, azt a publikus NEM nyitja! Emlékezzünk az aszim- 
metrikus algoritmus lényegére: két kulcs van, amit az EGYIK 
zár, azt csak és kizárólag a MÁSIK nyitja! Így Henry maxi- 
mum még egyszer titkosíthatja a levelet (mintha mégegy- 
szer ráfordítaná a zárat) , de kinyitni nem képes. Mégegyszer: 
a publikus kulcsot bárkinek odaadhatjuk, hisz publikus. A 
privát kulcs védelméről kell gondoskodnunk: jelszóval véde- 
ni, Smart Cardon tárolni vagy lenyelni. 
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Digitális aláírás - deszkamodell 

A kétkulcsú titkosítások kapcsán kell megemlékeznünk a di- 
gitális aláírásokról. Talán e lap olvasói közt nincs olyan, aki 
a digitális aláírást úgy képzeli el, hogy beszkenneljük a fő- 
nök aláírását és azzal a bitmappel manipulálunk valamit. A 
digitális aláírás felhasználói között azonban bőven vannak 
ilyen személyek. Őket júzereknek hívjuk, és valahol a mi kö- 
zös felelősségünk (az Ön felelőssége is, Kedves Olvasó!) , hogy 
megszabadítsuk kényszerképzeteiktől ezeket az emberi lé- 
nyeket. Mit tud a digitális aláírás? Pont arra képes, mint a 
hagyományos: lehetetlenné teszi, hogy egy adott dokumen- 
tumot a rendelkezésünkre álló időintervallum alatt, s a ke- 
zünk ügyébe eső eszközkészlettel meghamisítsuk. Szó sincs 
rejtjelezésről, titkosításról! Egy aláírt (pl. közbeszerzési) 
szerződés esetleg teljesen publikus lehet - Utópia államban. 
Az aláírás szerepe, hogy a bárki által elolvasható dokumen- 
tumot ne lehessen könnyedén meghamisítani. Most nézzük 
meg a digitális aláírás folyamatának deszkamodelljét: 





a A digitális aláírás deszkamodellje 


A jobboldali feladó saját kulcspárjának privát tagjával tit- 
kosítja a dokumentumot, de mellé teszi a kibontáshoz, elol- 
vasáshoz nélkülözhetetlen publikus kulcsot. Így bárki képes 
kibontani és elolvasni az iratot, de senki sem képes azt 
meghamisítva ismét visszacsukni, hogy úgy tűnjön, hogy az 
eredeti feladó készítette. Miért nem? Mert a feladó szigorú 
őrizet alatt tartja a privát kulcsát, senkinek oda nem adja. 


A valóság 

Sajnos a gyönyörű elméletek sokszor megbuknak a gyakorlat 
próbáján. Nincs ez másként az RSA algoritmussal sem. Desz- 
kamodelljeink a fenti formában működésképtelenek azon 
egyszerű oknál fogva, hogy az RSA hihetetlenül lassan dol- 
gozik. Ha valóban ráeresztenénk egy másfél megás Word do- 
kumentumra, elfogadhatatlan válaszidővel lenne képes azt 
D-edik hatványra emelni (nem is ezt teszi, de jól hangzik. . .:-)! 
Összehasonlító tanulmányok szerint a nyílt kulcsú titkosítás 
három nagyságrenddel lassabb, mint szimmetrikus párja. A 
valóságban sohasem tisztán használjuk az RSA-t, hanem egy 
másik algoritmussal karöltve. Így mindkettőnek kihasznál- 
hatjuk az előnyeit, és megszabadulhatunk a hátrányoktól. 

A titkosítás deszkamodelljét tehát módosítanunk kell: NEM a 
teljes dokumentumot titkosítjuk a címzett publikus kulcsával, 
mert az túl lassú lenne, hanem a feladó generál magának egy 
random szimmetrikus (például 3DES) kulcsot, azzal villámgyor- 
san titkosítja a dokumentumot, majd az RSA következik, és tit- 
kosítja a 3DES kulcsot, hogy azt ne kelljen SMS-ben átküldeni 
a fogadó félhez. Így a nyílt kulcsú titkosítás erősségét para- 
dox módon a benne használt szimmetrikus algoritmus erőssé- 
ge határozza meg. Hacker Henry választhat: vagy az RSA-t tö- 
ri (kulcshossztól függően mintegy négymilliárd év), hogy hoz- 
zájusson a 3DES kulcshoz, vagy közvetlenül nekiesik a doksi- 
nak és 3DES törést alkalmaz (szintén mintegy négymilliárd év). 
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A digitális aláírás deszkamodellje pedig így változik: NEM 

a teljes dokumentumot titkosítjuk a feladó privát kulcsá- 

val, mert az túl lassú lenne, hanem ehelyett egy, a doku- 

mentumra jellemző egyedi azonosító kerül be az RSA fo- 

gaskerekei közé. Kitalálták már mi az? A dokumentumból 

képzett hash (például MD5)! Tehát a hálózaton a követke- 

ző ,tárgyak" utaznak: 

"0 az eredeti dokumentum 

21 a dokumentumból képzett hash, titkosítva a a feladó 
privát kulcsával 

"0 a feladó publikus kulcsa 

Az aláírás sértetlenségét pedig így állapítjuk meg: 

1. Vedd a megkapott doksit, és hash-eld meg 

2. Vedd ki a csomagból a feladó publikus kulcsát, és nyisd 
ki a titkosított hash-t 

3. Ha az előző két lépés azonos hash-t ad, a doksi sértetlen. 


The Man In The Middle 

Szép is, jó is, de nem azért találták fel a kapanyelet, hogy 
az időnként ne süljön el. Vegyük elő ismét a titkosított do- 
kumentumküldés deszkamodelljét, de most lesz mégegy 
szereplőnk: Hacker Henry, aki a két kommunikáló fél közé 
ékelődve minden hálózati forgalmat elkap, és saját kénye- 
kedve szerint módosít: 





a Hacker Henry , bedolgozik" a kulccserébe 


A feladó bejelenti DO, hogy titkosított üzenetet szeretne 
küldeni. Ezt az üzenetet Hacker Henry elfogja, kiveszi a há- 
lózatból, és saját üzenetével helyettesíti. A címzett úgy ér- 
zékeli, hogy nem Henry kíván neki titkosított üzenetet kül- 
deni. Szokás szerint elküldi a publikus kulcsát a vélelmezett 
feladónak, tehát Henrynek O, aki azt köszöni szépen, majd 
saját kulcspárjának publikus részét küldi el a feladónak (ezt 
szemlélteti, hogy itt más a kulcs alakja). A feladó kap egy 
publikus kulcsot, hite szerint a címzettét, s azzal titkosítja 
az üzenetet (illetve, mint tudjuk: az üzenet titkosítására va- 
lójában felhasznált szimmetrikus kulcsot). Ezt elküldi Henry- 
nek 8), aki vidáman elolvassa a saját privát kulcsával. Hen- 
ry nem tett mást, mint kicserélt minden kulcsot, amely át- 
ment a keze között. Magát a támadásformát igen nehéz vég- 
rehajtani, mert kevés olyan pont van az Interneten, ahol a 
csomagok egytől egyig átmennek - kizárólag a feladó és a 
címzett Internetszolgáltatójának alkalmazottai lennének ké- 
pesek erre. De az elvi lehetőség is lehetőség! Tenni kellene 
ellene valamit! Biztosítani kellene a hálózaton utazó kul- 
csok kicserélhetetlenségét. Hogyan? Hát digitális aláírással! 
Kellene egy harmadik fél, akiben mindenki megbízik, és nem 
tesz mást, mint aláírogatja a kulcsokat. Olyan, mint egy 
közjegyző. Az ő informatikai neve: 


Certificate Authority 
Vagy röviden CA. A CA feladata nem más mint mások pub- 
likus kulcsainak hitelesítése, hogy ha kapunk egy publikus 
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kulcsot mely tökéletesen úgy tűnik, mintha Samukától szár- 
mazna, akkor biztosak lehessünk abban, hogy ez valóban 
azé, akié. Minden egyes kulcspárunk publikus tagját be- 
küldjük a CA-nak, aki arra ráteszi saját digitális aláírását - 
hisz neki is van saját kulcspárja, amivel aláírogathat. Az 
aláírt publikus kulcs neve hitelesítési bizonyítvány. 


HETE a fs 


General ] Detais ] certification Path ] 


22] 








Certificate Information 


This certificate is intended tor 


"s Allovis data on disk to be encrypted 
eprotects e-mad messages 
sProves your identity to a remote computer 


Issuedto: MarcellFoti 


Issued by: Netácodermia CA 


Valid from 11/20/2000 to 11/20/2001 


§? vouhave a private kay that corresponds to this certficate. 





a Egy hitelesítési bizonyítvány 


Mit jelent ez a gyakorlatban? Azt, hogy az én publikus kul- 
csomat bárki elolvashatja, de a rendelkezésére álló idő alatt 
meg nem hamisíthatja, hisz ahhoz szüksége lenne a CA pri- 
vát kulcsára. Minden megbízható CA úgy vigyáz a privát kul- 
csára, mint a szeme fényére, vagy talán még annál is job- 
ban. Jobb helyeken (pl. Verisign egyes komolyabb bizonyítvá- 
nyai) a CA nemcsak hogy nem lóg az Interneten, de be sincs 
kapcsolva, sőt, komoly, akár fegyveres őr védelme alatt áll. 
Már csak azt kell biztosítani, hogy 

1. amikor én beadom hitelesítésre a publikus kulcsomat, 
menet közben senki se cserélhesse le, és 

2. senki se léphessen fel a nevemben kulcskérőként 

E két szabály úgy teljesíthető a legkönnyebben, ha nem há- 
lózaton, hanem más módon, például személyesen juttatom 
el a publikus kulcsomat a CA-hoz, ami egyben jó lehetősé- 
get nyújt a második pont betartására, hisz ha másképp 
nem, a személyi igazolványommal hitelt érdemlően bizo- 
nyíthatom a testület előtt, hogy én én vagyok. (De még a 
legjobbak sem tévedhetetlenek. Tavasszal a Verisign hitelesí- 
tett két, szoftvereredetiség igazolására szolgáló publikus kul- 
csot a Microsoft nevére. A bökkenő csak az, hogy - amint az 
később bebizonyosodott - akik besétáltak az irodába, NEM 
álltak a Microsoft alkalmazásában. Így most van kint a világ- 
ban két olyan hitelesítési bizonyítvány, mely semmisnek te- 
kintendő.) Amint rákerült a CA aláírása a publikus kulcsom- 
ra, már használhatom is. Íme a folyamat: 
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2. Hellő, levet szeretnék írni 


Baz 





3. Íme a titkosítő kulcs 








5. Megy a levél 





5 A kulcshitelesítés folyamata 


A vindózom generál egy RSA kulcspárt, melynek publikus 
tagját beküldöm O, és jó pénzért aláíratom egy közjegyző- 
vel, s ezután ha valaki kéri a publikus kulcsomat, akkor nem 
pucéron adom oda neki, hanem a CA által aláírt, hitelesí- 
tett példányt kapja 0. Henry ugyan továbbra is elkaphat- 
ja, de meghamisítani, lecserélni nem tudja, mert nem áll 
rendelkezésére a CA privát kulcsa. Maximum a saját kulcs- 
párjának hitelesítésére bírja rávenni a CA-t, de azon a kul- 
cson onnantól virítani fog, hogy ,ez Hacker Henry publikus 
kulcsa". A feladó a megkapott bizonyítvány alapján, a CA 
publikus kulcsával elvégzi az aláírás valódiságának ellenőr- 
zését 9, s ha minden rendben, akkor használatba is veszi. 
Ha eltérést tapasztal, sikít. 

Kész. Azazhogy. Izé. Tessékmondani, hogy került a levél- 
feladó oldalára a CA publikus kulcsa? Talán csak nem háló- 
zaton keresztül? Mert ha igen, azt Henry bizonyára le is 
cserélte menet közben. Hol itt a biztonság? Hol? 


Trusted Root Certificate 

Hát ott, hogy a CA publikus kulcsa NEM hálózaton keresztül 
kerül a mi számítógépünkre. Hanem akkor hogyan? Vettük 
a boltban? Igen, igen. Az operációs rendszerrel együtt vet- 
tük a szoftverboltban, és CD-n jutott el hozzánk. Ha Henry 
képes lenne préselt CD lemezeken kicserélni az azon tárolt 
kulcsot, nagy-nagy bajban lennénk. De mivel erre nem ké- 
pes, bizton állíthatjuk, hogy a CA-k publikus kulcsa sértet- 
lenül jutott el hozzánk: 































ETETNEK TT 21 

Intended purpose: [cats -] 

Intermediate Certification Authorities . Trusted Root Certification Authorities ] al] 

[dssved To [dssved gy Expíratio. .. ] Friendly Name a 
(Elmicrosoft Root Auth... Microsoft Root Authority  12/31/2020 Microsoft Root A... 
(Elnettodk Expressz (... . NetLock Expressz (Cla...  2/20/2019 — NetLock Express... 
(ElnetLock Közjeg NetLock Közjegyzol(C... 220/2019 — NetlockKozjegy... 
(Elnetlock Üzleti ( MetLock Uzleti (Class... 2/20/2019 — NetLock üzleti (C... 
ENO LIABILITY ACE... NO LIABILITY ACCEP... — 1/8/2004 — VeriőignTimeSt.. J 
(EJ PTT Post Root CA PTTPost Root CA 6726/2019 


(Edsaunalahden Serve... . Saunalahden Serveri CA. 6/26/2019 
(Eszunalahden Serve...  Saunalahden Serveri CA 6/26f2019 
(secure Server Certi... . Secure Server Certific...  1/8/2010 


Saunalahden Ser... 
VeriSignfRSA Se... ve] 





Import... Eper E Advanced... 
Certficate intended purposes es 








5 A megbízható CA-k listája a Windowsban. A telepítő 
CD-ről került oda valamennyi, így a magyar NetlLock is! 
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Untrusted Root 

Az előző oldalon látható bizonyítvány ,Issued by" sora 
szerint a kibocsátó a NetAcademia CA. Tökéletes bizonyít- 
ványokat képes kibocsátani. Egy nagy hibája van: semelyik 
gyárilag telepített Windowsban sincs benn ennek a CA-nak 
a publikus kulcsa. Ez azt jelenti, hogy az innen kibocsátott 
tanúsítványok leellenőrzésére nem túl sokan képesek a vi- 
lágban. Ez végülis nem gond, mert egy ilyen tanúsítvány- 
ból ki lehet szedni a benne lévő publikus kulcsot, éppen 
csak annak hitelességét nem tudjuk ellenőrizni - de attól 
még az egy jó RSA publikus kulcs. A benne lévő kulcs ha- 
misítatlanságának leellenőrzésére csak azok a gépek lesz- 
nek képesek, amelyekre valamilyen módon eljuttatom a CA 
publikus kulcsát. Minden más helyen ez fogad: 


EZETIZTSZTESENEEZEEES ETTE 2] 


JON Information you exchange with this site cannot be viewed or 
gú changed by others. However, there is a problem with the sites 
security certificate. 


ÚN The seculy cettiicate was issued by a company you have 
not chosen to trust. View the certificate to determine whether 
ou want to trust the certilying authority. 


9 Thesecurity certificate date is valid. 


€ The security certificate matches the name of the page you 
are uying to view. 


Do you want to proceed? 


maa]] View Certificate 








5 Nem ellenőrizhető a bizonyítvány - de attól még mű- 
ködik! 


Ilyenkor két választásunk van: 
"2 Vagy elfogadjuk a bizonyítványt ,as is", vagyis ellenőri- 
zetlenül 
-0 Vagy elvetjük, mint megbízhatatlant 
Az első lépésnek is lehet értelme. Ha csak az a gond, hogy 
nincs meg nálam a CA publikus kulcsa, és mondjuk egy 
weblapot kellene elérnem HTTPS://-en (SSL) keresztül, 
megfontolnám a jeszt, ha az SSL nem titkosítási okokból 
kell, hanem például tűzfal megkerülésére :-). (Az SSL egyik 
kiváló tulajdonsága, hogy a titkosított webforgalomba a 
köztünk lévő tűzfal nem tud belekotyogni, hisz titkosított. 
Ezt a trükköt használhatjuk Exchange 2000 OWA használa- 
tára olyan tűzfalon keresztül, mely nem engedi át a 
WebDAV-ot. De ha titkosítom...!) 


CA hierarchia 

Az eldöntendő igenen és nemen kívül lehet mégegy esé- 

lyünk: ha a CA nem árván áll a világban, hanem egy olyan 

CA hierarchia része, melynek gyökerét ismeri a Windows, 

akkor a probléma nem lép fel, mivel: 

"B Ha az idegen CA által kibocsátott bizonyítványt nem tud- 
ja ellenőrizni a Windows, megpróbálja magának a CA- 
nak a hitelesítését 
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"2 Ha a CA hitelesítése sem megy, megpróbálja a CA fölöt- 
ti CA hitelesítését 
b Ha az sem megy az afölöttit mindaddig, amíg el nem éri 
a CA hierarchia csúcsát - hisz annak publikus kulcsa 
ott virít telepítés óta a Windowsban. 
Ez azt jelenti, hogy a fa bejárásához állandó hálózati kap- 
csolat kell? Szó sincs róla! Itt és most szögezzük le: a lo- 
kálisan meglévő Root Certificate-k miatt a Verisign (és a 
többi root) gépeit akár ki is lehet kapcsolni. Ha ez a rootra 
igaz, nyilván az egymásra épülő CA-alantasokra is igaz. A 
CA hierarchia leellenőrzése tipikusan lokálisan megtörté- 
nik, mivel (jobbára) minden bizonyítvány magával hordoz- 
za a szülei és dédszülei digitális aláírását is, valahogy így: 


EZTET NEEE ETT 1 2121 


General [ Detais ) certfication Path ] 






Certificate Information 





erti 





frumral [doctz coíeztonvan] 
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0 Egymást hitelesítő bizonyítványok láncolata 


Ha elmúlik a bizalom 

A bizonyítványokon alapuló azonosítás feltételez egy jó 
adag bizalmat a hitelesítőszervezet iránt. A CA-k általában 
rá is szolgálnak a bizalomra, és nem adják ki privát kulcsu- 
kat. Nem így a végfelhasználók! ők bizony elhagyják, pub- 
likussá teszik, eladják a velük ,összenőtt" privát kulcsot, s 
ha ez kiderül, szükségessé válhat a bizonyítvány visszavo- 
nása. Erre való az úgynevezett Certification Revocation 
List, vagyis érvénytelenné vált bizonyítványok feketelistá- 
ja. Minden aláírásellenőrzőnek elvileg kutya kötelessége 
lenne ellenőriznie, hogy a bizonyítvány a matematikai 
megfelelőségen túl megbízható-e még? Mivel azonban ez 
állandó hálózati forgalommal járna, a CRL ellenőrzése a 
munkaállomáson alapállapotban ki van kapcsolva. 


A nyílt kulcsú rendszereket az X.509 szabvány írja le. A bi- 
zonyítványok kezelését pedig a PKCS H7-H1O szabványok. A 
következő alkalommal a PKCS H1 leírással, vagyis az RSA 
algoritmussal foglalkozunk! 


Fóti Marcell 
MCSE is. 
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Internet Security 


and Acceleration Server 


Bővítmények (Extensions) 

A bővítmények további funkciókkal gazdagítják az ISA Servert. 
Az ISA Server által kiszolgált kapcsolatok adatfolyamaihoz 
hozzáférve lehetővé teszik, hogy ezeken további szűréseket és 
megfigyeléseket végezzünk. A POP3 szűrő (POP3 filter) például 
nem meglepő módon arra szolgál, hogy kiszűrje a közzétett 
POP3 kiszolgáló ellen elkövetett buffer overrun támadásokat. 
E havi cikkünkben az ISA Server-ben gyárilag megtalálható 
bővítményeket tekintjük át, természetesen nagyobb figyel- 
met fordítva azokra, melyek biztonsági szempontból a leg- 
fontosabbak. A bővítmények beállításait a megszokott ISA 
Server MMC-n keresztül érhetjük el a tömb, majd ezután az 
Extensions/Application filters kiválasztásával. Ha valaki 
esetleg további részletekre kíváncsi, vagy nem találja meg 
cikkünkben a kívánt segítséget, érdemes megtekinteni az 
ISA Server súgóját, ahol a bővítmények igazán elismerésre 
méltó részletességgel vannak ismertetve. 


DNS behatolásészlelő szűrő (DNS intrusion detection filter) 
A DNS intrusion detection filter elcsípi, majd elemzi a bel- 
ső hálózat felé irányuló DNS forgalmat. Az alábbi négy for- 
galomtípus figyelését állíthatjuk be: 

"8 DNS név túlcsordulás (DNS hostname overflow). A DNS 
név túlcsordulás akkor történik, ha a DNS válasz egy név- 
feloldási kérésre túllép egy bizonyos meghatározott 
hosszúságot. Azokban az alkalmazásokban, melyek nem 
ellenőrzik a név hosszát, túlcsordulhatnak a belső puffe- 
rek, ezzel pedig lehetővé válhat tetszés szerinti parancsok 
végrehajtása a megcélzott számítógépen (Ez itt a reklám 
helye: a NetAcademia security tanfolyamán bővebb ismere- 
tek szerezhetők a buffer overrun-ról, és annak veszélyeiről) . 

"1 DNS hossz túlcsordulás (DNS length overflow). Az IP címek- 

re vonatkozó DNS válaszok tartalmaznak egy hossz mezőt, 

ami négy bájt hosszúságú lehet. Egy hibásan (bizonyos 
szempontból mindegy, hogy véletlenül vagy szándékosan 
hibásan) formázott DNS válasz következtében túlcsordul- 
hatnak a belső pufferek, és lehetővé válhat tetszés sze- 
rinti parancsok végrehajtása a megcélzott számítógépen. 

DNS zone transfer from privileged ports (1-1024), vagyis 

DNS zónaátvitel kérés az alsó portokról. Ez akkor törté- 

nik, amikor egy rendszer olyan DNS ügyfélalkalmazást 

használ, amely a belső kiszolgálókról való zónaátvitel- 
nél forrásportként egy alsó portot (1-1024) ad meg. 

6 DNS zone transfer from high ports (1024 fölött). A fenti- 
hez teljesen hasonló, de ez a magas forrásportokat 
megadó kapcsolatokat figyeli. 

Mindenképpen ajánlott a DNS intrusion detection filter 

használata, és annak beállítása, hogy mind a négyféle te- 

vékenységet figyelje. A beállítások elvégzéséhez válasszuk 
ki a DNS intrusion detection filter objektumot, jobbklikk, 
majd válasszuk a Properties menüpontot. 
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Fontos tudni, hogy erre a szűrőre vonatkoznak a DNS intru- 
sion alert settings-ben beállított riasztások. Ennek a riasz- 
tásnak bekapcsolva kell lennie (persze a működéshez nem fel- 
tétlen szükséges, csak erősen ajánlott), és jó, ha olyan riasz- 
tást küld, ami igen gyorsan magára vonja az illetékes rend- 
szergazda figyelmét. Alábbi ábránk az általunk javasolt beál- 
lítást tartalmazza. E beállítások következtében bármely DNS 
intrusion eseményre ISA Server-ünk elkezd riasztásokat kül- 
deni. (A beállításokat az alerts alatt a DNS intrusion alert tu- 
lajdonságlapjának (Properties) előcsalogatásával érhetjük el). 





EHENTHETEZESTTSEBNNNT 32lz 
General Event: [ Action: ] 
Event fonSinnson az] 
Descinor [Ahoz nans ovedios lengik evez 5077 
4 2 
Adálional condítiere ány ONS intrusion -] 
By server: err vi 





Actions will be executed when the selected condtions occut: 


TT Number of sccurences before the det is issued: Ik 
IT Mumber ol everts per second before the alert sisevedt PT 
Recutting acticns ae peformed: 

G immediately 

C Alte manual reset of alert 

C Mtimesince last executionis more than [7 minutes 
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a A DNS Intrusion Detection riasztás beállításai 


Van még néhány dolog, amit jó tudni a DNS intrusion 
detection filter-ről: Először is, ez a szűrő a belső hálózat fe- 
lé irányuló forgalmat figyeli, az ISA Server-re irányuló gya- 
nús kapcsolatok nem fognak riasztást előidézni. Másodszor, 
bár ez a filter igen hasznos tud lenni, ne alapozzuk erre tel- 
jesen a védelmünket. A Windows 2000 igen erősen a DNS- 
re támaszkodik. Ha egy támadó megszerzi belső hálózatunk 
zónafájlját/zónafájljait, az igen nagy előnyt jelent számá- 
ra. Éppen ezért bizonyosodjunk meg róla, hogy a belső DNS 
kiszolgálók nem látszanak a külső hálózat felé. Ha mégis 
szükséges DNS adatokat a nyilvánosság elé tárni, tegyük ezt 
a DMZ-ben (DMZ-ből) , és csak azok az adatok legyenek elér- 
hetők, melyek tényleg szükségesek a külső felhasználóknak. 
(Ha minden igaz, következő havi cikkünkben épp ezt a téma- 
kört járjuk majd körül részletesebben) 


FTP access filter 

Ez a bővítmény egy olyan állatfajta, aminek beállításával 
kevés teendőnk lesz, mivel összesen egyféle beállítási lehe- 
tőség van. Vagy bekapcsoljuk, vagy nem. Ez a szűrő továb- 
bítja az FTP kéréseket a biztonságos címfordítás 
(SecureNAT) ügyfelektől a tűzfalszolgáltatáshoz. A szűrő di- 
namikusan megnyitja az FTP protokoll által igényelt másod- 
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lagos portokat, és elvégzi a NAT ügyfeleknek szükséges 
címfordítást. Általában ajánlott ezt a szűrőt bekapcsolva 
tartani (ez az alapértelmezett állapota is). 


H.323 protokollszűrő 

A H.323 protokollszűrő biztosítja a H.323 alkalmazások (pél- 
dául NetMeeting) számára, hogy működhessenek az ISA 
Serveren keresztül is. Ha a szűrő be van kapcsolva, megnyitja 
az ISA Server külső lábán az 1720-as portot, éppen ezért érde- 
mes kikapcsolva tartani, ha nem használjuk a H.323 protokollt. 


HTTP átirányítást végző szűrő (HTTP redirector filter) 
Ez a szűrő annyiban hasonlít az FTP access filter-hez, hogy 
továbbítja a tűzfal és SecureNAT ügyfelektől érkező HTTP ké- 
réseket a Web Proxy szolgáltatáshoz. Ez a szűrő szükséges az 
ISA alapvető funkcionalitásának biztosításához, ezért tart- 
suk bekapcsolva (ez az alapértelmezett beállítás is). Ha kö- 
vetjük azt az ajánlást is, mely szerint mindig a Web Proxy 
ügyfelet használjuk a HTTP elérés biztosítására, kapcsoljuk 
be azt a HTTP redirector opciót, mely visszautasítja a tűzfal 
és SecureNAT ügyfelektől érkező HTTP kéréseket. 


POP behatolás-észlelő szűrő (POP intrusion detection filter) 
A Post Office Protocol (POP) behatolás-észlelő szűrő elkap- 
ja, és elemzi a belső hálózat felé irányuló POP forgalmat. Ez 
az alkalmazásszűrő a POP buffer overflow támadásokat fi- 
gyeli, és észleli. Az ilyen támadás a DNS szűrőnél leírtakhoz 
hasonlóan történik, vagyis a támadó megpróbál buffer over- 
flowt előidézni a kiszolgálón, és ha ez sikerült, szabad a pá- 
lya. A szűrő felhasználásának természetesen vannak korlátai 
(ahogy az a behatolás-észlelő technológiáknál megszokott 
is). Ettől függetlenül, ha már POP3 kiszolgálót teszünk köz- 
zé, mindenképpen ajánlott ennek a szűrőnek a használata 
(ez az alapértelmezett beállítás is), és a hozzá tartozó riasz- 
tás DNS szűrőnél beállítotthoz hasonló beállítása is. 






POP Intrusion Properties] Ez 
General] Event: Aztion: ] 
T Send exrai 
SMTP server 
To: 
Cc: 





From 





7. Progam 
Fun this progra 


FAShutDoun Mal bat 
SelAccsunt 


7. Report to Windows 2000 event log 
TT Stop selected servizes 
TT Stan selected servizes 


OK Canczt Arzply 


Use this account 














5 POP3 behatolásészlelés riasztás által végrehajtott 
cselekvés beállítása 


Az ISA Server megszakítja a POP kapcsolatot a riasztás 
megtörténtekor. Ez viszont nem tartós! Vagyis a kedves tá- 
madó a kapcsolat megszakítása után azonnal újra tud kap- 
csolódni a közzétett POP kiszolgálóhoz. Ennek elkerülésé- 
re van lehetőségünk: a riasztást beállíthatjuk úgy is, hogy 
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állítsa le a POP3 szolgáltatást, ha behatolási kísérletet ész- 

lelt. Ezt a POP intrusion alert Actions füle alatt tehetjük 

meg. Arra, hogy ezt beállítsuk-e, nincs kötelező érvényű 

szabály, de érdemes végiggondolni a következőket: 

B Mennyire nélkülözhetetlen ez a szolgáltatás? 

-B Mennyi idő alatt lehet beállítani a szükséges védelmet, 
és újraindítani a szolgáltatást? 

0 Kit érint a szolgáltatás kiesése? 


RPC szűrő (RPC Filter) 

Az RPC szűrő, bármilyen hihetetlenül is hangozzék, RPC ki- 
szolgálók közzétételét teszi lehetővé, így ezek is elérhető- 
vé válhatnak a külső ügyfelek számára. A szűrő leggyako- 
ribb alkalmazása az Exchange Serverek közzététele; de ha 
úgy döntünk, hogy Exchange kiszolgálónkat inkább az 
SMTP, POP3, és/vagy IMAP4A protokollok használatával 
tesszük közzé, ajánlott ezt a szűrőt kikapcsolni. 


SMTP szűrő (SMTP filter) 

A Simple Mail Transfer Protocol (SMTP) szűrő elcsípi az 
összes SMTP forgalmat, ami az ISA Server SMTP portjára 
(25-ös port) érkezik. A szűrőnél lehetséges olyan szűrési 
mechanizmusok beállítása, amelyek számos paraméter 
(például küldő, csatolt fájl típusa, csatolt fájl neve) alap- 
ján visszadobhatják a közzétett SMTP kiszolgálók felé tar- 
tó üzeneteket. A szűrő megvizsgálja az adott forgalmat, és 
csak akkor engedi tovább, ha a szabályok ezt megengedik. 
Az üzenetkezelés megfelelő szűrését üzembe állítani iga- 
zán szép feladat. Erre sem lehet igazán jó kötelező jellegű 
vFeceptet" adni, hiszen vannak olyan tényezők, melyek 
minden ISA Server-nél mások és mások (például belső leve- 
lezőrendszer, vírusszűrés). Itt is érvényes az, ami minden- 
hol: ha elakadna valaki és a cikkben nem talál választ, 
használja bátran az ISA súgóját. 

Fontos tudni, hogy a többi bővítménnyel ellentétben az SMTP 
szűrő alapértelmezésben nincs bekapcsolva. Ha ISA Server 
mögötti SMTP kiszolgálókat teszünk közzé, ajánlott bekap- 
csolni, és az alább leírtak szerint beállítani az SMTP szűrőt, de 
figyeljünk nagyon, amikor ezt tesszük, mert akár saját ma- 
gunk is előidézhetünk szolgáltatás megtagadást (DoS). Mie- 
lőtt nekilátunk egy éles ISA Serveren az SMTP szűrő beállítá- 
sának, feltétlen olvassuk el az [1] knowledge base cikket. 


Csatolt állományok (Attachments) fül 

Az ez alatt a fül alatt található opciók azt a célt szolgál- 

ják, hogy a leveleket a csatolt állományok neve és kiter- 

jesztése alapján szűrjük. Azoknak a csatolt fájloknak a 

blokkolása, melyek futtatható állományokra utalnak, igen 

hasznos lehet a vírusvédelem szempontjából, de minden- 
képpen figyelembe kell vennünk két dolgot. 

1. Általában nem célszerű minden olyan csatolt fájlt blokkol- 
ni, ami veszélyes lehet, hiszen ezek között biztosan lesz 
olyan is, ami cégünk működéséhez szükséges (például Word 
dokumentumok is tartalmazhatnak makrókat, mégsem kell 
ész nélkül eldobni őket. Legyen ez a vírusirtók feladata) . 

2. AzISA Server csatolt állomány szűrőjében van egy ismert 
hiba. Az időszakos szabályok érvénytelenné válhatnak, 
ilyenkor egy szép piros x jelenik meg rajtuk, a szűrő vi- 
selkedése pedig előre nem látható módon megváltoz- 
hat. További információk erről a [2] címen találhatók. 
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A fentiek miatt javasolt, hogy ha használni akarjuk ezt 
a szűrőt, előbb teszteljük a majdani szabályokat, ezzel 
biztosítva, hogy az éles rendszerben az elvárásoknak 
megfelelően fognak működni. 
Annak eldöntése, hogy mely csatolt állományokat kívánjuk blok- 
kolni, sok tényezőn múlik, de azért van néhány olyan dolog, amit 
érdemes figyelembe venni. Én személy szerint például nehezen 
tudom elképzelni, hogy épeszű ember pif kiterjesztésű fájlt küld- 
jön. Bezzeg a Sircam! Az alábbi lista tartalmazza a leggyakrab- 
ban előforduló futtatható állományokat, és szkriptfájlokat. 
.bas, .hta, .msp, .url, .bat, .inf, .mst, .vb, .chm, .ins, .pif, 
.wbe, .cmd, .isp, .pl, .vbs, .com, .js, .reg, .ws, .cpl, .jse, 
.Scr, .wsc, .crt, .lnk, .sct, .wsf, .exe, .msi, .shs, .wsh 
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General Altackmenve ] Uszrs /Domsin: ) Keymords [ SMTP Carmanés [ 









Veumual have permszion to configure the enlepize pdicyin order 
to modíy these setfrg. 


Catogoy " Vake 


Estersün bat 
Estersön com 
Etarson se 
Eterenn 
Estersön ee 
Estorcon  .zé 
Estersön  .ibs 
Eotersin ébe 
Estersbn bő 
Esterson 













a Szűrés csatolt állomány neve/kiterjesztése alapján 


Felhasználók/Tartományok (Users/Domains) fül 

Ezek a beállítások lehetővé teszik, hogy adott felhasználó- 
tól (például jozsiDhekkersz.hekk) , vagy adott tartományból 
(például mindenki a hekkersz.hekk tartományból) érkező le- 
veleket kiszűrjünk, így ezek a felhasználók nem tudnak az 
SMTP kiszolgálónkon keresztül levelet küldeni. Ennek elsőd- 
leges célja nyilván az, hogy a spamet, és a veszélyes tartal- 











makat terjesztőket eleve kizárjuk a levélforgalomból. 
EKITEZTESTZZTEZTTSHHKTEKTNTTI 21] 
General] Altachmenys . Users / Donaine ] Keywords ] SMTP Conmands ) ! 
"You must have permssion to configure the errerprize pojcy in order to 
Hnodity theze setinge 
Senders 
Senders neme Rejected Senders 
jelis dfocbar.corn 
Domains 
Domain neme Rejected Vomans 
EZEN 





a Szűrés felhasználók és tartományok szerint 
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Kulcsszavak (Keywords) fül 

Ennek a segítségével tudjuk az üzeneteket a fejlécükben, vagy 
magában az üzenetben előforduló kulcsszó alapján szűrni. Ez 
segíthet például bizonyos vírusok terjedésének megakadályo- 
zásában (például szűrés az ILOVEYOU szóra), de szűrhetünk 
akár arra a bizonyos s-el kezdődő, x-re végződő szóra is... 
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Ceneral] Attactments ] Users / Donain:. Keywords [ SMTP Command ] 


Ycu must have permission to corfigure the entemprise policy in order 
settng;. 


tomodry these 





5 Szűrés kulcsszó alapján 


SMTP parancsok (SMTP Commands) fül 

Az SMTP commands fülön beállíthatjuk azokat a határérté- 

keket, melyek az SMTP kiszolgáló nevében ügyködő ISA 

Server által elfogadott egyes parancsok maximális méretét 

határozzák meg. Ajánlott az alapbeállítások megtartása, de 

célszerű a következő parancsokat letiltani: 

"1 EXPN. Az EXPN parancs megmutat egy disztribúciós listát, 
így a parancsot kiadó láthatja a listában szereplők cí- 
meit. Ez általában nem kívánatos. 

B VRFY. A VRFY parancs arra használható, hogy a parancsot 
kiadó ellenőriztesse az adott postafiók létezését. Jó sok 
címet lehetne így megtudni. Irtsuk ki! 

0 TURN. A TURN parancs megfordítja az ügyfél és kiszolgá- 
ló szerepkörét. Ez általában olyan környezetekben haszná- 
latos, ahol nem állandó kapcsolat (vagy IP cím) van. 
Ilyenkor a levelek például az Internetszolgáltató levelező- 
szerverére esnek be, majd a kapcsolat felépülésekor a cég 
levelezőszervere továbbítja a kimenő leveleket a szolgálta- 
tóhoz, és kiadja a TURN parancsot, vagyis megkéri a szol- 
gáltatónál levő kiszolgálót, hogy továbbítsa a nála várako- 
zó befelé jövő leveleket. Ha valakinek így működik a leve- 
lezése, az természetesen ne tiltsa le ezt a parancsot. 

2 NOOP. A NOOP kicsit hasonlít a pinghez, hiszen egy vá- 
laszkódot kér a kiszolgálótól. Ez nélkülözhető, így áldo- 
zatul esik a paranoiának. :) 
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General ] Attackmenis ] Users / Domain: ] Keywods . SMTP Commands ] 





Ycu must have permiszion to corfigure the entemprise policy in order 
to modiw these settinas. 
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c SMTP parancsok 


SOCKS V4 szűrő (SOCKS V4 filter) 

A SOCKS szűrő a SOCKS alkalmazásoktól érkező kéréseket a 
tűzfalszolgáltatáshoz továbbítja. 

Az ISA Server ezután ellenőrzi a hozzáférési szabályokat, 
hogy eldöntse, hogy az ügyfélnek engedélyezett-e a külső 
hálózattal folytatott kommunikáció. A szűrő használata el- 
sősorban a UNIX alkalmazásokkal való használhatósághoz 
szükséges. Alkalmazásának nincsenek biztonsági kockázatai, 
de jó tudni, hogy a SOCKS version 4 nem támogatja a fel- 
használó-azonosítást. A hozzáférésszabályozás SOCKS hasz- 
nálata esetén ezért csak IP cím alapján valósítható meg. 


Streaming Media szűrő (Streaming Media Filter) 

A streaming media szűrő használatával javítható az 
Internetelérés sebessége, mert a szűrő képes az ,élő 
adást" szétosztani. 

Ez azt jelenti, hogy a szűrő az információt csak egyszer 
szerzi meg a külső hálózatról, majd elérhetővé teszi azt 
több belső ügyfél számára. Speciális biztonsági beállítások 
(és kockázatok) nem tartoznak a szűrőhöz. 


SECURITY AND ACCELERATION SERVER (V. RÉSZ) 
Összefoglalás 
Röviden az alábbi beállítások javasoltak az ISA Server bő- 
vítményeinél: 


"B Kapcsoljuk be a DNS behatolásészlelő szűrőt, és állítsuk 
be úgy, hogy figyelje mind a négyféle tevékenységet. 
Állítsuk be hozzá a megfelelő riasztást is. 

Ne feledjük, hogy a DNS behatolásészlelő szűrő haszná- 

lata nem helyettesítheti a körültekintő tervezést. Bizo- 

nyosodjunk meg róla, hogy a belső DNS kiszolgálókat 
nem lehet kívülről elérni. 

Kapcsoljuk ki a H.323 szűrőt, ha nincs szükségünk a 

H.323 protokollra. 

Ha követjük azt az ajánlást is, mely szerint mindig a 

Web Proxy ügyfelet használjuk a HTTP elérés biztosítá- 

sára, kapcsoljuk be azt a HTTP redirector opciót, mely 

visszautasítja a tűzfal és SecureNAT ügyfelektől érkező 

HTTP kéréseket. 

Ha POP kiszolgálót teszünk közzé, kapcsoljuk be a POP 

behatolás-észlelő szűrőt. 

-? Ha lehet, kapcsoljuk ki az RPC szűrőt. 

0 Ha SMTP kiszolgálót teszünk közzé, kapcsoljuk be az SMTP 
szűrőt, és tiltsuk le az alábbi parancsok használatát: 
EXPN, VRFY, TURN, NOOP. Használjuk az üzenetek szű- 
résénél a csatolt állományok típusa és neve alapján 
történő szűrést is, ezzel sok veszélyes fájlt kiszűrhe- 
tünk. Állítsunk be bátran kulcsszó alapján végzett szű- 
rést is! Ennek különösen egyes vírusok terjedésének 
megakadályozásában vehetjük nagy hasznát. 

"0 Ne feledjük el azt sem, hogy szűrhetünk felhasználó és 
tartománynév szerint is, ami segíthet például a spam 
kiszűrésében. 

"8 Ha SOCKS ügyfeleket is szeretnénk használni, kapcsoljuk 
be a SOCKS szűrőt, de ne feledjük, hogy ez esetben a 
hozzáférések szabályozása csak IP cím alapján történ- 
het, felhasználók szerint nem. 

Itt a vége, fuss el véle! A következő hónapban terveink 

szerint a biztonságos DNS környezet kialakítását fogjuk át- 

tekinteni. 
BP, MCSE 


A cikkben szereplő URL-ek: 


[1] http://support.microsoft.com/support/kb/articles/0292/0/10.ASP 
[2] http://support.microsoft.com/support/kb/articles/ 0292/0/14.ASP 
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E havi számunkban az adatkezeléssel, az adatbázisok, adat- 
tárak elérésével foglalkozunk. Ebben az ActiveX Data Objects 
(ADO) objektumcsalád lesz segítségünkre, amely a DAO-t 
leváltva és az ODBC-t egyre inkább kiszorítva lett napjainkra 
az egyik leggyakrabban használt adatelérési felület. Az adat- 
báziskezelés (sőt, még az ADO professzionális használata is) 
olyan szerteágazó és részletes téma, hogy az nemcsak az 
újságot, de még egy teljes könyvet is megtöltene; éppen 
ezért a következő néhány oldalon az ADO alapjait, valamint 
az alapvető adatkezelési műveleteket mutatjuk be. Akit a 
téma részletesebben is érdekel, az látogassa meg a Weben 
az ADO objektummodell referenciáját [2]. A példaprogramok 
- mint mindig - az [1] címről letölthetők. 


Mi az az ADO? 

Az ADO egy COM objektummodeltl, ami az OLE DB nevű adat- 
báziskezelő komponens , tetején" működik. Az OLE DB 
bevezetésének célja az volt, hogy adatbázistól független, 
uniform adatkezelési felületet nyújtson a programozóknak. 
Az OLE DB-t és a különféle adatbázisokat providereknek 
nevezett szoftverkomponensek kapcsolják össze (ezeket a 
providereket általában az egyes adatbáziskezelők gyártói 
készítik, de a Windows önmagában is tartalmaz néhányat). 
Az ADO tehát nem más, mint egy COM felület az OLE DB 
felett, ami lehetővé teszi, hogy azt minden ActiveX-kom- 
patíbilis nyelvből elérhessük (Visual Basic-ből, ASP-ből, 
egyszerű VBScript és JScript scriptekből) - míg az OLE DB-t 
szinte csak a C programozók használták. 

Az uniformizált adatelérés ötlete nem új: a Windows évek 
óta tartalmazza az úgynevezett ODBC réteget. Az ODBC 
hasonló módon működik, mint az OLE DB: az adatforrások 
és az ODBC közötti kapcsolatot ott is külön ,eszközmeghaj- 
tók", termékspecifikus ODBC driverek tartották fenn. Az 
ADO előnye, hogy az OLE DB providereknek köszönhetően 
az ODBC kikerülésével is elérhetjük az adatforrásokat - 
ugyanakkor létezik egy OLE DB provider, ami lehetővé teszi, 
hogy ADO-n keresztül ODBC adatforrásokat kezeljünk. 

Az ADO, az OLE DB providerek és az ODBC driverek közötti 
viszonyt jól szemlélteti az alábbi ábra: 


(1313) 








OLE DB 
provider-ek 





Jet SOL] [oracle 008C 


? 














Adatkezelés 


(X. rész) 
. rész 
DO-va 


Egy szó mint száz: az ADO segítségével könnyen és azonos 

módon érhetjük el az adatforrásokat, akár közvetlen OLE 

DB, akár ODBC kapcsolaton keresztül. A használható adat- 

források száma csak attól függ, hogy mihez találunk 

providert, esetleg ODBC drivert: manapság a tabulált 

szöveges fájltól az Access vagy SOL relációs adatbázisokon 

át akár egészen az Exchange Server levéltáráig sokminden- 

hez hozzáférhetünk. A Windows 2000-ben alapértelmezés- 

ben telepített OLE DB providerek: 

8 Microsoft Jet 4.0 OLE DB Provider - Access (Jet, ".mdb) 
adatbázisokhoz 

"8 Microsoft OLE DB Provider for Indexing Service - az 
Indexing Service eléréséhez 

0 Microsoft OLE DB Provider for Internet Publishing - 
webtárak, FrontPage webek eléréséhez 


0 Microsoft OLE DB Provider for ODBC - ODBC adatforrásokhoz 

B Microsoft OLE DB Provider for Oracle - Oracle adat- 
báziskezelőkhöz 

b Microsoft OLE DB Provider for SOL Server - SOL Server 
adatbáziskezelőkhöz 

0 Microsoft OLE DB Simple Provider - egyszerű szöveg- 
fájlokhoz 


0 OLE DB Provider for Microsoft Directory Services — cím- 
társzolgáltatások eléréséhez 
Ezeken kívül, ODBC segítségével elérhetjük az alábbiakat: 
8 Vesszővel elválasztott vagy tabulált szövegfájlok 
(".txt, ".csv, ".tab) 
b Access adatbázisok, Excel adattáblák (".mdb, ".xls) 
0 dBase, Visual FoxPro, Paradox adatbázisok (".dbf, ".db) 
-? SOL Server, Oracle adatbáziskezelők 
További providerek természetesen külön telepíthetők (újab- 
bak jelennek meg például az SOL Server vagy az Exchange 
Server telepítésekor). A Microsoft Data Access Components 
(MDAC) legújabb verziója (a cikk írásának pillanatában a 
2.6) a [3] címről tölthető le. 


Az ADO objektummodell 
Bemelegítésképpen lássuk az ADO objektumcsalád tagjait: 
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0 Az ADO, az OLE DB provider-ek, az ODBC driver-ek és 
az adatforrások viszonya 
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5 Az ADO objektummodellje (a kollekciókat árnyékkal 
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Magyarázat, egyelőre röviden, mert az egyes objektumokat 
majd használat közben fogjuk igazán megismerni: 

- Connection objektum: az egyik legfontosabb objektum, 
egy adatbázissal való kapcsolatot reprezentál. A 
munkát általában a Connection objektum létrehozásá- 
val, majd az adatbázishoz való kapcsolódással kezdjük 

0 Recordset objektum: a másik legfontosabb objektum. A 
Recordsetet kezdetben úgy képzeljük el, mint egy 
eredménytáblát, amelyben soronként találhatók a 
rekordok. Minden rekordnak több mezője (Field) lehet 
(extrém esetben akár minden rekordnak más és más), 
ezek a mezők a táblázat oszlopai. 

0 Field objektum, Fields kollekció: Egy rekord (vagy 

Recordset) egy mezője. A Field objektumokat általában 

a Fields kollekció segítségével érjük el. 

Record objektum: egy Recordset egy sora, vagy akár egy 

különálló rekord. A Record objektum is mezőkkel 

(Fields) rendelkezik. 

"I Command objektum: parancsok, beépített eljárások, 
lekérdezések futtatására használható objektum. 
Lényegesek a hívott eljárás bemenő paraméterei 
(Parameters kollekció, Parameter objektumok); ered- 
ményként általában (bár nem feltétlenül) Recordset-et 
kapunk vissza. 

0 Stream objektum: régi ismerős; bináris és szöveges 
folyamok, adatok kezelésére, mozgatására használható 
objektum. 

0 Property objektum, Properties kollekció: az objektumok- 
nak sok olyan jellemzőjük van, ami közvetlenül nincs 
kivezetve. Ezeket a jellemzőket név szerint, az adott 
objektum Properties kollekciójában található Property 
objektumokon keresztül érhetjük el. 

"B Error objektum, Errors kollekció: az adatkezelés közben 
felmerült hibákat tartalmazza. 


ADO konstansok 

Az ADO programozása során sokszor találkozunk konstan- 
sokkal. E konstansok értékének keresgélése sok-sok 
felesleges munkával jár. Szerencsére a Windows mind a 
VBScript-hez, mind a JIScripthez tartalmaz megfelelő, 
beilleszthető fáljt, ami tartalmazza a konstansok definí- 
cióját. A fájlokat keressük a NProgram FilestCommon 
FilesYSystemyado mappában; a VBScript-hez használatos 
fájl az adovbs.inc, míg ha JScript-ben dolgozunk, az ado- 
javas.inc-t másoljuk ki a munkamappába. Ha az ASP oldalak 
elején a következő paranccsal beillesztjük a megfelelő fájlt, 
a kódban már nyugodtan használhatjuk a konstansokat: 


€1-- HINCLUDE FILE-"adovbs.inc" --5 

Ennek a megoldásnak az a hátránya, hogy használata 
esetén akaratlanul is megnöveljük az ASP oldalaink mére- 
tét. Ha ezt nem szeretnénk, a webalkalmazásunk global.asa 


fájljába típuskönyvtárként is felvehetjük az ADO-t: 


£€1-- METADATA TYPE-"typelib" FILE-"C:XProgram 
HW FilesilCommon FilesilSystemladolmsadol5.dil" --5 


Ezután a kódokban minden további nélkül használhatjuk az 
ADO konstansait. A példaprogramokban az egyszerűség 
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kedvéért mindig a konstansok valódi értékét használjuk, és 


megjegyzésként feltüntetjük a konstans nevét. 


Kapcsolódás az adatbázishoz 
A cikk során az aspsuli.mdb Access (Jet) adatbázist 
használjuk, ami letölthető az [1] címről. Ez az adatbázis az 
SOL Server-ben jól ismert Northwind adatbázis néhány 
érdekes tábláját tartalmazza. Aki rendelkezik SOL Server-rel, 
az a kapcsolódási fájlokat átállítva akár közvetlenül az SOL 
Server-ben is dolgozhat. A példaprogramok feltételezik, 
hogy az adatbázis- és konfigurációs fájlok a C:(dbN könyvtár 
alatt találhatók. A példaprogramok letöltési helyén lévő db 
könyvtárban található fájlokat ide másoljuk majd be. 
Az adatbázisok eléréséhez magának az adatbázisnak nem 
kell (sőt, nem is szabad) a webes területen lennie. Az adat- 
bázishoz megfelelő jogosultságokat kell definiálnunk (ha 
pl. az aspsuli.mdb-hez az anonymous internetes felhasználó- 
nak nincs írásjoga, nem fogja tudni módosítani a tartalmát, 
sem pedig új adatokat felvenni bele); ezeknek a hozzáférési 
jogosultságoknak viszont semmi keresnivalójuk olyan 
helyen, ahol a webes ügyfél közvetlenül elérhetné őket. 

Ha már tudjuk, milyen adatbázishoz szeretnénk kapcsolód- 

ni, az ADO-nak háromféle módon adhatjuk meg: 

8 Az úgynevezett Connection String segítségével. A 
Connection String egy szöveges változó, amely minden, 
a kapcsolódáshoz szükséges információt (adatbázis 
helye, felhasználónév, jelszó, stb.) magában hordoz. 

-? Data link File segítségével. A Data Link File tulajdonkép- 
pen egy fájlba mentett Connection String, azonban 
van két nagyon nagy előnye: egyrészt, a kódba nem 
kell magát a Connection Stringet beleírni, csak a Data 
Link File nevét; így a működő rendszer alatt egyetlen 
mozdulattal, a fájl átírásával kicserélhetjük az adat- 
bázist. Másrészt, a Data Link File ügyes konfigurációs 
varázslót tartalmaz, így nem nekünk kell a Connection 
String előállításával és szintaxisával bajlódnunk. 

"8 ODBC adatforrások, DSN-ek segítségével. Ha az ODBC 
Manager-ben definiáltuk a megfelelő System Data 
Source Name-t (DNS-t), az ADO-nak elég azt átadnunk 
a kapcsolódáshoz. 


A Data Link File 

A Data Link File - mint mondtam - nem más, mint egy 
szövegfájlba mentett Connection String. Előnye viszont, 
hogy a Connection String-et nem kézzel kell előállítani. 
Próbáljuk ki: hozzunk létre egy üres szövegfájlt, majd nevez- 
zük át .udl kiterjesztésűre! Az ikonja megváltozik, és ha ket- 
tőt kattintunk rá, megjelenik a Data Link Properties dialógus: 








az] cse] tap 





5 A Data Link dialógus 
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A Provider oldalon kiválaszthatjuk, hogy melyik OLE DB 
providert szeretnénk a kapcsolathoz használni. Ezután a Next 
gombra kattintva megjelenik a Connection fül, aminek tar- 
talma az előzőleg választott provider típusától függ (hiszen 
providerenként más és más adatokat kell megadnunk). A pél- 
daprogramban a Jet 4.0 (Access) provider-t választottuk, 
majd a következő oldalon megadtuk a használni kívánt adat- 
bázis nevét (c: Idbtaspsuti.mdb) . Ha a Test Connection gomb- 
ra kattintunk, az eszköz megpróbálja a megadott adatok 
alapján felépíteni a kapcsolatot, és értesít az eredményről. 
Ne felejtsük el, hogy a Data Link fájlt felhasználóként hozzuk 
létre. Amikor az adatbázist ASP oldalból szeretnénk használ- 
ni, az anonymous Internetfelhasználó nevében tevékenyke- 
dünk - előfordulhat, hogy a Data Link létrehozásakor minden 
jónak tűnik, és ASP alól mégsem működik. Ilyenkor 
valószínűleg arról van szó, hogy az anonymous Internet fel- 
használó (IUSR cgépnév: illetve most már inkább a Web 
Anonymous Users csoport) nem rendelkezik a megfelelő 
jogosultságokkal az adatbázis eléréséhez. 

Nyissuk meg NotePaddel az előbb létrehozott .udf fájlt: 


CINEZETI 
Fie Edk Format Help 

ToTzdbI § 2 
; Everything after this line is an OLE 06 initstring a. 
Provídéremiérosoft. Jet. OLEDB.4.0;Data Sourcesc:VdbVáspsuli.mdb;Persist 1 
jSecurity InfosFalse 1 


1D2d 














a A Data Link File csak egy szövegfájlba mentett 
Connection String (a szöveg kijelölt része) 


ODBC kapcsolat létrehozása 

Ha ODBC kapcsolatot szeretnénk használni, úgynevezett System 
Data Source Name-et (System DNS-t) kell létrehoznunk. Ehhez 
a vezérlőpultban keressük meg a Data Sources (ODBC) ikont (az 
Administrative Tools alatt bujkál) , és indítsuk el az eszközt: 


MITTZZKETTT TT" 22] 
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a án ODBC. Syalem dola saace etoroz irtormakon about howvta esznsettő 
onihiz machine, inciudng NT services. 








ca Ha ODBC kapcsolatot szeretnénk használni, System 
DNS-t hozzunk létre 


Az Add... gombra kattintva megjelenő varázslóban válasszuk 
ki a használni kívánt driver-t (a fenti példában a Microsoft 
Access Driver-t) , majd a Finish-re kattintva töltsük ki a továb- 
bi mezőket. A Data Source Name mezőben adjunk a kapcso- 
latnak egy egyedi nevet (ezzel fogunk hivatkozni rá), majd 
válasszuk ki, melyik adatbázist szeretnénk használni. 


A Connection objektum 

Bár az adatbázis-kapcsolatot nem feltétlenül kell a 
Connection objektum segítségével előre létrehozni (egy-egy 
Recordset . megnyitásához vagy Command objektum 
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használatához az ADO képes azt menet közben is létrehozni) , 
mindenképpen hatékonyabb, ha előre megtesszük azt. Első 
lépésként hozzuk létre a Connection objektumot (conn1.asp): 


Set oConn -— 


4 Server.CreateObject("ADODB.Connection") 


Az objektum létrehozása után első dolgunk az adatbázis- 
kapcsolat megnyitása lesz. Ehhez az objektum .Open() 
metódusát használhatjuk. A metódus első paramétere 
határozza meg a megnyitni kívánt kapcsolatot, és lehet: 
8 egy Data Link File neve (, File Name-" előtag után): 


oConn.Open "File Name-C:ldblaspsuli.udl" 
"8 ODBC System DSN neve (,DSN-" előtag után): 
oConn.Open "DSN-AspSuli" 


B ... és persze lehet maga a komplett Connection String 
is, például: 


oConn.Open "ProviderzMicrosoft.Jet.OLEDB.4.O; 
4 Data SourcezC:)dblaspsuli.mdb; 


4 Persist Security InfozFalse" 


Az .Open() metódus ezen kívül még három paramétert 

kaphat, ezek megadása azonban nem kötelező. Sorrendben: 

-? UserID - a kapcsolathoz használt felhasználónév, ha itt 
megadjuk, az felülbírálja a Connection String-ben 
definiált értéket 

-? Password - a kapcsolathoz használt jelszó, ha itt meg- 
adjuk, az felülbírálja a Connection String-ben definiált 
értéket 

- Options - ha értékét adAsyncConnect-re (16) állítjuk, a 
kapcsolódás aszinkron menne végbe; a kapcsolódás 
befejezésekor pedig a ConnectComplete esemény 
következne be. Ezt a funkciót ASP-ben (események 
hiányában) azonban nem használhatjuk. 

Ha a kapcsolat megnyitása nem sikerül, hibát kapunk visz- 

sza, amit kezelhetünk. Emellett bármikor ellenőrizhetjük a 

Connection objektum .State jellemzőjét is; értéke az alábbi 

konstansok valamelyike lehet: 














Lele ea HOT EG 

adStateClosed 0 — AwKkapcsolat zárva 

adStateOpen 1 — AKkapcsolat nyitva 
adStateConnecting 2 Kapcsolódás folyamatban 
adStateExecuting 4 — Parancs végrehajtása folyamatban 
adStateFetching 8 Eredmények visszaadása folya- 


matban 


A kapcsolat lezárása 

A munka befejeztekor a Connection objektum .Close() 
metódusának meghívásakor zárjuk le a kapcsolatot. A 
valóságban a kapcsolat azonban nem szakad meg: mivel az 
adatbázishoz való kapcsolódás az egyik leglassabb művelet, 
az OLE DB bizonyos ideig tárolja a kapcsolatokat, hátha 
ezidő alatt érkezik egy újabb kérés, ami pontosan ugyanazt 
az adatbázist, pontosan ugyanolyan paraméterekkel 
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szeretné elérni (ez egyébként elég gyakori eset). Ilyenkor 
az OLE DB nem épít fel új kapcsolatot, hanem a meglévő, 
korábban már lezárt példányt használja fel újra. Fontos 
tudni viszont, hogy az újrafelhasználás nem egyenlő a 
párhuzamos felhasználással, tehát az OLE DB egy kapcso- 
latot addig nem oszt ki másnak, míg az nyitva van - 
helyette kénytelen újat létrehozni. Éppen ezért próbáljuk a 
Connection objektumot a lehető legkésőbb megnyitni, és a 
munka végeztével a lehető leghamarabb bezárni. 


A Recordset objektum 

Az adatokat legtöbbször az adatbázis egy részének 
táblázatos nézetén keresztül kezeljük. Ez a táblázatszerű 
adathalmaz nálunk egy Recordset objektum képében 
jelenik meg, valahogy így: 
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a A Recordset objektum táblázatos formában 


A Recordset tehát sok-sok rekordot (sort) tartalmaz, és 

minden rekord több mezőből (oszlop) áll. Az aktuális rekor- 

dot a kurzor jelzi (az ábrán látható nyilat is felfoghatjuk 
kurzornak) . A kurzort a Recordseten belül elmozdíthatjuk; 

a műveleteket (írás-olvasás) pedig az aktuális (kurzor által 

mutatott) rekordon végezzük. 

A Recordset megnyitásakor definiálnunk kell, milyen kur- 

zort szeretnénk majd használni. A kurzorokat két kategória 

szerint csoportosíthatjuk: a kurzor típusa és a kurzor helye 
szerint. Típus szerint az alábbiak lehetnek: 

B Static (adOpenStatic, 3): Statikus kurzor esetén a rekor- 
dokról másolat készül, és a Recordsetben már csak a 
másolaton dolgozunk. Az adatbázisban történt vál- 
tozások menet közben nem jelennek meg a 
Recordsetben, és az adatok nem is módosíthatók. A 
kurzort előre és visszafele is mozgathatjuk. 

0 Forward Only (adOpenForwardOnly, 0): Az így létrehozott 

Recordset hasonló a statikushoz, azzal a különbséggel, 

hogy itt a kurzor csak előre mozoghat. Ez az 

alapértelmezett kurzortípus. 

Dynamic (adOpenDynamic, 2): A dinamikus kurzorral 

létrehozott Recordsetben minden, a létrehozása óta 

végrehajtott változás is látható, a kurzort mindkét 
irányba mozgathatjuk. Ez a legdinamikusabb, és egy- 
ben , legköltségesebb" kurzortípus 

"B KeySet (adOpenkeyset, 1): A keyset kurzor hasonló a 
dinamikus kurzorhoz, azzal a különbséggel, hogy az így 
létrehozott Recordsetben a többi felhasználó által a 
Recordset létrehozása óta törölt vagy létrehozott reko- 
rdok nem láthatók (a meglévő rekordokban történt vál- 
tozások igen). 


8) 


A fenti értékeket a Connection illetve a Recordset objek- 
tum .CursorType jellemzőjeként állíthatjuk be, illetve a 
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Recordset objektum .Open() metódusának paramétereként 
adhatjuk át. Az alapértelmezés - mint már említettük - a 
forward-only kurzor; az adatok egyszeri legyűjtéséhez 
tökéletesen elég. Ugyanakkor, ha az adatokban módosíta- 
nunk kell, a forward-only kurzor már kevés. 
A kurzorok másik fontos tulajdonsága a kurzor helye. 
Nevezetesen, hogy a kurzort a kiszolgáló vagy pedig az 
ügyfél kezeli-e. Alapértelmezés szerint (és ha azt az adat- 
báziskezelő provider-e is támogatja), a .CursorLocation 
jellemző értéke adUseServer (2), azaz a kurzor kiszol- 
gálóoldali. Ha azt szeretnénk, hogy a teljes Recordset az 
ügyfélnél tárolódjon - vigyázzunk, ennek adatforgalmi 
folyományai vannak -, a kurzort a klienshez küldhetjük az 
aduUseClient (3) értékkel. 
Mielőtt végre elkezdenénk használni a Recordsetet, még 
egy dolgot ki kell tárgyalni, az pedig a rekordok zárolása 
(Locking) . Ahhoz, hogy ugyanazt az adatot két felhasználó 
egyidőben ne tudja módosítani, a módosítás idejére zárol- 
ni kell. Ez a zároló mechanizmus természetesen létezik az 
OLE DB-ben, de többféle módon is működhet, attól füg- 
gően, hogy a .LockType jellemzőnek milyen értéket adunk: 
"B adLockReadOnly (1) - csak olvasható Recordset, így 
biztosan nem lesz szükség a rekordok zárolására. Ez az 
alapértelmezés, tehát ha az adatokat módosítani 
szeretnénk, a zárolás típusát meg kell változtatnunk. 
8 adLockPessimistic (2) - pesszimista zárolás; a provider 
a rekord bármelyik mezőjének módosításakor zárolja a 
rekordot 
"Ph adLockoOptimistic (3) - optimista zárolás; a provider 
csak a módosítások érvényre juttatásakor (az .Update() 
metódus idejére) zárolja a rekordot 
"I adLockBatchOptimistic (4) - kötegelt optimista zárolás; 
a  provider csak a változtatások kötegelt 
érvényesítésekor (az .UpdateBatch() metódus alatt) 
zárolja a rekordokat. 


Recordset létrehozása, megnyitása 

Recordsetet létrehozhatunk önmagában, majd csatlakoz- 
tathatjuk egy adatbáziskapcsolathoz (vagy hagyhatjuk a 
memóriában, sokszor tökéletes  tárolóeszköz); illetve 
Recordsethez jutunk akkor is, ha a Connection vagy a Command 
objektum .Execute() metódusát meghívjuk. Vesézzük ki először 
az első esetet: egy újonnan létrehozott Recordset objektumot 
hozzárendelünk egy már meglévő adatbáziskapcsolathoz, majd 
abból megnyitunk egy táblát (rs1.asp): 


Set oConn -— 
4 Server.CreateObject("ADODB.Connection") 
oConn.Open "File Name-C:ldblaspsuli.udl" 


Set oRS - Server.CreateObject("ADODB.Recordset") 
oRS.Open "Products", oConn, , , 2 "adcmdrable 


While Not oRS.EOF 
Response.Write oRS("ProductName") §£ "CBR2" 
ORS.MoveNext 


WEnd 


OoRS.Close 


oConn.Close 
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A Recordset Open metódusának paraméterei a következők: 

"b A végrehajtandó parancs (SOL kifejezés, tábla vagy tárolt 
eljárás neve, Command objektum, stb.) 

"2 Az aktív adatbáziskapcsolat Connection objektuma 

"0 A használni kívánt kurzortípus (ha nem adjuk meg akkor 

adOpenForwardOnly) 

"0 A használni kívánt zárolási stratégia (ha nem adjuk meg, 
akkor adLockReadOnly) 

"0 Az első paraméterként átadott adat értelmezésére, valamint 
végrehajtására vonatkozó adatok, például: 








Konstans Érték Jelentés: az első paraméter... 
adCmdText 1 SOL kifejezés vagy tárolt eljárás 
neve 

adCmdrTable 2 Tábla neve 





adCmdStoredProc 4 Tárolt eljárás neve 





adCmdUnknown 8 Ismeretlen (alapértelmezés; az ADO 


fogja eldönteni, hogyan értelmezi) 





adCmdFile 256 Fájlba mentett Recordset objek- 


tum fájlneve 
A példában egy alapértelmezett, csak olvasható 
Recordsetet nyitottunk a Products táblára. 
Navigálás a Recordsetben 
Két fontos jellemző az elejére: 
B .BOF - értéke True, ha a kurzor a Recordset első reko- 
rdja előtt áll 
I .EOF - értéke True, ha a kurzor a Recordset utolsó rekordja 
után áll 
Ha a Recordset .BOF és .EOF jellemzőinek értékei egyaránt 
True, a Recordset üres. A kurzor mozgatása: 
"0 .MoveNext() - a kurzor a következő rekordra lép 
"8 .MovePrevious() - a kurzor az előző rekordra lép 
"B .MoveFirst() - a kurzor az első rekordra lép 
8 .MoveLast() - a kurzor az utolsó rekordra lép 
Lássuk csak mégegyszer az előző példa közepét: 


While Not oRS.EOF 

Response.Write ORS("ProductName") § "CBR2" 
ORS.MoveNext 

WEnd 


Egy dolog nem ismert még: az aktuális rekord adott mezőjét 
- például - az oRS(mezőnév) hívással érhetjük el. Minden 
másnak ismerősnek kell lennie: egy ciklust formálunk mind- 
addig, amíg a Recordset kurzora az utolsó utáni pozícióra 
nem lép. A kurzor folyamatos mozgatását a cikluson belül 
kiadott .MoveNext() hívások biztosítják. 


Tipikus hiba, hogy a cikluson belül elfelejtjük a 
:MoveNext() metódust meghívni. Az eredmény 
ilyenkor egy végtelen ciklus (hiszen a kurzor sosem 
fog a Recordset végéig elérni); rajta segíteni csak az 
adott webalkalmazás - rosszabb esetben az IIS szol- 
gáltatás - újraindításával lehet! 


A Fields kollekció 

A Recordset mezőit a fenti közvetlen hivatkozásnál okosabban 
is elérhetjük, ha kihasználjuk a Fields kollekció illetve a Field 
objektum nyújtotta előnyöket. Az rs2.asp egy SOL kifejezést 
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futtatva visszakapott Recordset mezőinek néhány adatát, majd 
a rekordok minden egyes mezőjét listázza nekünk. 


For Each oField In oRS.Fields 
Response.Write "CBR2Nev: " § oField.Name 
Response.Write "CBR2Tipus: " § oField.Type 
Response.Write "CBR:Meret (definialt): " § 
4 — oField.DefinedSize 
Response.Write "cCBRoxMeret (pillanatnyi): " a 
4. oField.ActualSize 
Response.Write "CBR2" 


Next 


A rekord mezőit jelképező Field objektumnak sok jellemző- 
je van, a neve (.Name) és értéke (.Value) mellett a leg- 
fontosabb talán mégis a típus (.Type). Ez lehet például (a 
teljes listát lásd: [3]): 

















Konstans aA SG HOTEG 

adSmalllnt 2 Egész szám (kétbájtos) 
adlnteger a Egész szám (négybájtos) 
adCurrency 6 Pénzbeli érték 

adBoolean 11 Logikai érték (igaz/hamis) 
adDate 7 Dátum 

adVarWChar 202 Unicode szöveges változó 





adLongVarWChar 203 Hosszú Unicode szöveges érték 
(megjegyzés, note) 

Bináris érték 

Hosszú bináris érték 


adBinary 128 
adLongVarBinary 205 





A listcats.asp és a listemps.asp további lehetőségeket 
mutat be. Egyrészt, láthatjuk, hogy az adatok megje- 
lenítésének módját függővé kell tenni az adatok típusától: 


Select Case oField.Type 
Case 6: " adCurrency (penz) 
Response.Write FormatCurrency(oField.Value ) 
Case 7: ! adDate (datum) 
Response.Write FormatDateTime( oField.Value ) 
Case 205: "adLongVarBinary (kep) 
Response.Write "CIMG src-""photo.asp? 


b t-Categoriesáf-Picture§" § 





CategoryIDsid-" § ORS("CategoryID") § 
hl am ejen 

Case Else: Response.Write oField.Value 
End Select 


A pénzügyi adatokat a VBScript FormatCurrency(), a 
dátumértékeket a FormatDateTime() függvénye segítségé- 
vel formázzuk meg. A bináris adat ebben az adatbázisban 
egy fényképet jelent, ezért ennek a megjelenítéséhez létre- 
hozunk egy speciális URL-t, ami a photo.asp oldalt meghív- 
va átadja annak a használt tábla és mezők nevét, valamint 
annak azonosítóját. A photo.asp pedig az átvett értékek 
alapján kimenetén tiszta bináris adatot ad vissza, és ehhez 
segítségül hívja az ADODB.Stream objektumot is: 


Set ost - Server.CreateObject("ADODB.Stream") 


ost.Type - 1 "adTypeBinary 


ost.Open 
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ost.Write oRS( sPhotoField ) 
osSt.Position — 78 " A kep tartalma 78.-tol kezd. 
Response.ContentType - "image/bmp" 


Response.BinaryWrite oSt.Read 


A példában megnyitunk egy Stream objektumot, majd 
kiolvassuk a fényképet tartalmazó mezőből a bináris ada- 
tot. Az adatbázis jellegzetessége, hogy ez a bináris adat 
egy 77 bájtos fejlécet is tartalmaz, ami nem tartozik a 
képhez, ezért nem kell visszaadni (ezért pozícionáljuk a 
Stream objektumot a 78. bájtra). Ezután a Response objek- 
tum ContentType jellemzőjét (a válasz MIME típusát) beál- 
lítjuk ,/mage/bmp"-re, majd binárisan elküldjük az ügyfél- 
nek a Stream objektum tartalmát. 


Adatok módosítása 

Ha adatokat kiolvasni már tudunk, itt az ideje, hogy 
módosítsunk is. A példaadatbázis terméktáblájában 
(Products) a UnitPrice mező tartalmazza a termék 
egységárát. Hozzunk létre egy olyan oldalt, ami a 73-as 
azonosítójú (ProductID) termék (egyébként vörös kaviár) 
pillanatnyi egységárát 1099-kal megnöveli! A teljes kód a 
kaviar.asp példaprogramban található. 


Set oConn - 
4 Server.CreateObject("ADODB.Connection") 
oConn.Open "File Name-C: dblaspsuli.udl" 

Set OoRS 5 Server.CreateObject("ADODB.Recordset") 
ORS.Source - "SELECT $ FROM Products 

5 WHERE ProductID-73" 


ORS.ActiveConnection 5 oConn 


ORS.CursorType - 2 ! adopenDynamic 
ORS.LockType -— 3 " adLockoptimistic 
oRS.Open , , , , 1 " adcCmdText 
Response.Write "Előtte: " § 


4  FormatCurrency( oRS.Fields("UnitPrice") ) 
oRS.Fields("UnitPrice") 5 
4 oRS.Fields("UnitPrice") $ 1.1 


ORS.Update 
ORS.Reguery 1 ! adcmdTrext 
Response.Write " -- Utána: " § 


4 FormatCurrency( oRS.Fields("UnitPrice") ) 
oRS.Close 


oConn.Close 


A példaprogram első részét is érdemes megfigyelni. Látható, 
hogy a Recordset megnyitása előtt a legtöbb jellemzőt 
egyedileg is beállíthatjuk, és az .Open() metódusnak csak az 
utolsó paraméterét kell átadnunk (vagy azt sem). Figyeljük 
meg, hogy dinamikus kurzort nyitottunk, és optimista zárolási 
stratégiát választottunk. Ezután kiírjuk a termék aktuális árát. 
Itt most az adatokhoz nem közvetlen, hanem a Fields kollek- 
ción keresztül fértünk hozzá (ez a , szebb" írásmód). 

Az adatok módosítása egyszerű: a kívánt mező(k) értékét 
írjuk felül, majd a módosítások érvényre juttatásához 
hívjuk meg a Recordset Update metódusát. 

A változások elvileg azonnal megjelennek a mi 
Recordsetünkben is (hiszen dinamikus kurzort használ- 
tunk), de a demonstráció kedvéért mi a .Reguery() metó- 
dus segítségével újra lekérdezzük, frissítjük a Recordset 
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tartalmát. A .Reguery() metódus egyetlen paramétere az 
.Open()-nél is megadott lekérdezés típusa. 


Rekordok hozzáadása és törlése 

Meglévő rekordok adatait már tudjuk módosítani, most 
nézzük meg, hogyan lehet új rekordokat létrehozni, illetve 
meglévő rekordokat törölni. A regionadd.asp a régiók 
táblázatába (Region) felveszi Európát, 5-ös azonosítóval, a 
regiondel.asp pedig törli azt. 

A regionadd.asp lényeges része: 


ORS.AddNew 
oRS.Fields("RegionID") - 5 
oRS.Fields("RegionDescription") - "Europe" 


oRS.Update 


Az egyetlen újdonság (amellett, hogy most nem SOL 
lekérdezés eredményét, hanem a komplett táblát nyitottuk 
meg), a Recordset .AddNew() metódusában van. Paraméter- 
ként átadhatnánk neki az újonnan létrehozott rekordhoz 
tartozó mezők listáját, illetve azok értékeit, de ha nem 
tesszük, az új rekord örökli a tábla mezőit. Az .AddNew() 
hívása után a kurzor az újonnan létrehozott rekordra áll, az új 
rekord mezőinek értékét pedig az előbb ismertetett módon 
állíthatjuk be. Figyeljük meg, hogy bárhol áll a kurzor, az új 
rekord mindig a tábla végén jelenik meg; valamint hogy a 
kód többszöri futtatásával újabb és újabb Európa sorok 
születnek (mert az adatbázisban nincs kikötve, hogy a rekordok- 
nak egyedieknek kell lenniük) . 

A regiondel.asp törli az (első) Európa sort: 


ORS.Open "SELECT t FROM Region WHERE 
W RegionID - 5", oConn, 2, 3, 1 

" adopenDynamic, adLockoptimistic, adcCmdText 
If oRS.BOF And oRS.EOF Then 

Response.Write "Nincs ilyen rekord.cCBR2" 
Else 

oRS.Delete 
End If 
oRS.Close 


Lépésenként: lekérdezzük az összes 5-ös azonosítójú sort 
(Európa). Ha van ilyen, meghívjuk a Recordset .Delete() 
metódusát. Végül, bezárjuk a Recordset-et. 
A .Delete() metódust paraméter nélkül használva az 
aktuális rekordot törli (az .Update() hívására nincs szük- 
ség). Ha ez így nem megfelelő, a metódus paramétereként 
meghatározhatjuk, hogy mely rekordokat szeretnénk töröl- 
ni - erről (és az ADO további elemeiről) a következő szám- 
ban lesz szó. 
Fülöp Miklós 
mick Onetacademia.net 


kise era íg ALATTA 


[1] http://technet.netacademia.net/download/asp/10 
[21 http://msdn.microsoft.com/library/en-us/ado270 
/htm/mdmscadoapireference.asp 

[3] http://msdn.microsoft.com/library/en-us/ado270 
/htm/mdcstdatatypeenum.asp. ; 
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Windows automatikus kilépés 

K: Az lenne a kérdésem, meg lehet-e oldani NT, és W95 alatt 
hogy automatikusan kilogoljon a hálózatból, és visszamenjen 
a bejelentkező képernyőhöz, mintha a bezárja az összes prog- 
ramot, és belép más néven" -t választom a kilépésnél. Van er- 
re valami program, amivel el lehet ezt érni? Gondoltam, hogy 
átnevezem .scr-nek, és beteszem képernyővédőnek. 

V: A kérdés arra az alapvető fontosságú biztonsági feladat- 
ra utal, hogy hogyan léptessük ki az inaktív felhasználókat, 
mielőtt más használná a jogosultságaikat. 

A megoldást a Microsoft Windows NT Server 4.0 Resource 
Kit tartalmazza. A képernyővédő gondolat helyes elképze- 
lés, valóban a reskitben megtalálható WinExit program: egy 
speciális képernyővédő. A képernyővédő meghatározott idő 
letelte után szabályosan kilépteti a bejelentkezett felhasz- 
nálót. Egyéb tulajdonságai más képernyőkímélőkhöz hason- 
lóan a Vezérlőpult-zKépernyő-sKépernyőkímélő menüben 
állíthatóak be és tesztelhetőek. 

Ha azokat a programokat is be kell zárni, melyek nem men- 
tett adatokat tartalmaznak, be kell jelölni a , Force applica- 
tion termination" opciót. 

Forrás : NetAcademia Windows 2000 Lista 


MS Exchange: Törölt levelek visszaállítása 

K: Egy felhasználó törölte a levelei egy részét, ezt szeretném a jö- 
vőben elkerülni. A kérdésem a következő: Hogyan lehet beállítani 
az Exchange Servert úgy, hogy néhány napig a levelek visszaállít- 
hatóak legyenek valahogy? (Láttam, hogy az Outlookban van egy 
nRecover deleted item" menü, de ez sajnos szürke). 

V: Ahhoz, hogy a véglegesen letörölt levelek egyáltalán 
visszaállíthatóak legyenek, szükség van az Exchange beépí- 
tett funkciójára, mely a Deleted items (törölt elemek) , tehát 
az egyszer letörölt levelek végleges törlése után is lehetősé- 
get biztosít meghatározott ideig a levelek visszaállítására. 


ADATRA RIT 


(ÉN NEM TUDOM, MIT CSE. 
NÁLTAM, DE ELTŰNT EGY 
CSOMÓ FOLDEREM! 








ÉS AKKOR ÜLTEM A GÉP ELŐTT, AZ 
EGÉR MEGINDULT MAGÁTÓL, FÖL- 
ALÁ ROHANGÁLT A KÉPERNYŐN, VÉ- 


kilépés 

Azt, hogy az Exchange mennyi ideig tegye visszaállítható- 
vá a leveleket, a ,Deleted Mail Message Retention Time" 
pont alatt lehet beállítani. 
Ha egy meghatározott mailboxra vagy könyvtárra kell beállíta- 
ni, akkor az Exchange Server adminisztrációs programjában az 
adott mailbox vagy a public folder megnyitásával kezdhetjük. 
Ki kell választani a Limits fület és ott a , Use This Value (Days)" 
mezőben a visszaállíthatóságot lehet beállítani napokban. 
Ha egy private vagy public IS -re kell beállítani, akkor az 
Exchange Server adminisztrációs programjában Server con- 
tainert alatt az adott private vagy a public IS kiválasztásá- 
val kezdhetjük. Ki kell választani a General fület és ott a 
sDeleted item retention time (days)" mezőben a visszaál- 
líthatóságot lehet beállítani napokban. 
A levelek nem minden esetben visszaállíthatóak a fenti vé- 
delem ellenére sem. Ha a leveleket a következő , HARD 
DELETE" módon töröljük, akkor nem maradnak meg: 
8 Törlés SHIFT--DEL-lel 
2 IMAP vagy más olyan kliens törölte a levelet, ami nem 

helyezi be a Deleted Items könyvtárba 
2 A törlést egy offline dolgozó felhasználó végezte, aki szink- 

ronizálás előtt letörölte a levelet a Deleted Items-ből 
Az alapbeállítás szerint csak a Deleted Items könyvtárra van 
aktiválva a ,Deleted Item Recovery". Ha az Inbox, Outbox 
stb. mappákra is használni akarjuk, a következő Registry 
beállítás szükséges a munkaállomásokon: 


HKEY LOCAL MACHINENSOFTWAREMWMicrosoftNlExchanget 
4, €lientloptions 


DumpsterAlwaysOn-1 


Ez választ ad az eredeti kérdésre is, miért volt ,szürke" a 
Deleted Items Recovery. 
Forrás : NetAcademia Exchange Lista 


http://vilagokorseg.hu 
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Webszolgák és Weburak 


Két számmal korábban láttuk, miért van szükség a SOAP-ra 
(Simple Object Access Protocol): ha szeretnénk barátságban 
látni a különböző gyártóktól származó rendszereket, és új ala- 
pokra helyezni az Internetes alkalmazások kommunikációját. 
Választ kaptunk a miértre. Az előző számban megnéztünk egy 
konkrét SOAP kiszolgáló- és ügyfélimplementációt, a Micro- 
soft SOAP Toolkit-re építve (az COM alapú volt, emberek!). 
Láttunk egyféle hogyant. Most pedig beletekintünk a jövőbe, 
és megnézzük, hogy mire jó ez az egész SOAP mizéria (ezút- 
tal szigorúan .NET alapokon) . Hogyan tudja egy hétköznapi al- 
kalmazásfejlesztő felhasználni az új technológiákat? Mi az a 
Webszolga? (Webszolga: a Webservice magyarításával jó sokat 
küzdöttünk. A szerviz nem jó szó, mert oda az autónkat visszük. 
A service, szolgálat, szolgasors, szervusz tő kézenfekvő félrefor- 
dításával jött a Webszolga szó. Bocsánat érte.) Hogyan kell ír- 
ni és használni? A válasz itt lapul a következő oldalakon. 


Mi az a Webszolga? 

A Webszolga nem más, mint olyan program, amely más 
programok számára nyújt szolgáltatásokat szabványos 
internetes protokollokon keresztül. Egy aktív weblap, pél- 
dául a www.netacademia.net emberek számára nyújt szol- 
gáltatásokat, információkat. Don Box szavaival élve, ha a 
fogyasztó szénalapú (ember, kutya), akkor az nem Web- 
szolga, viszont ha az információk fogyasztója sziliciumala- 
pú (számítógép program), akkor az egy Webszolga. 

A honlapok kiszolgálója HTTP szerver szokott lenni, ennyi- 
ben áll a hasonlóság, mert a Webszolgák mögött is legtöbb- 
ször egy felokosított webszerver áll. Ennek ellenére a 
Webszolga nem egy honlap! A webszerver és a HTTP proto- 
koll használata csak azért kézenfekvő, mert mindkettő a mai 
Internet gerincét képezi, és a legtöbb helyen a tűzfalak kí- 
méletesen bánnak a HTTP csomagokkal - átengedik őket. 
Emellett az előző részekben már megnéztük, hogy a HTTP 
protokollra könnyen ráültethetünk valamilyen paraméterkó- 
dolási réteget, így elég egyszerűen megvalósítható egy tá- 
voli funkció meghívása, azaz egy Webszolga felépítése. 
Eddig olyan jól (?) megvoltunk a COM komponenseinkkel, 
amelyek bizonyos szolgáltatásokat nyújtottak az alkalmazá- 
saink számára. Mégis, 


Mi változott? 

A világ. Egyre több olyan szolgáltatás működik és lesz a vi- 
lágban, amelynek a belső logikája számunkra érdektelen vagy 
nem nyilvános, de szükségünk lesz rá az alkalmazásunkban. 
Például írunk egy üzleti webalkalmazást, ami bankkártyás 
megrendeléseket vesz fel. Érdemes lenne minél korábban 
megtudni, hogy az adott bankkártya érvényes-e, létezik-e, 
satöbbi. Ez nem megy saját kútfőből, kell egy külső szerve- 
zet, akinek a rendelkezésére állnak ezek az infók, és hajlan- 
dó azokat könnyen elérhetően a rendelkezésünkre bocsátani. 
Készítünk egy alkalmazást, ami egy listában megjeleníti a ma- 
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gyar névnapokat és azok dátumait. Honnan vesszük a listát? 
Letöltjük az Internetről, begyűrjük egy adatbázisba, és onnan 
listázzuk ki az alkalmazás számára? És ki fogja frissíteni az 
adatbázist? Mi van, ha a Dzsoki szép ,magyar" név mellé fel- 
veszik a Dzsonit is április elsejei névnappal (már van gazdá- 
Ja)? Kellene valami módszer, hogy a központi nyilvántartó 
(anyakönyvi hivatal? Nem tudom.) könnyen felhasználható 
módon publikálhatná az adatokat, így az azt felhasználó al- 
kalmazások például hetente frissíthetnék az adatbázisukat. 
Szeretnénk minden felhasználó asztalán (desktop) kijelezni 
a holnapi időjárást. Kivágjuk a megfelelő részt valamelyik 
időjárásjelentő honlapból? Lehetséges, csak a sok rizsa kö- 
zül nehéz lesz kiszedni azt a pár sornyi értékes infót. 
Miért adnak vissza sokszor badarságot a webes keresők? 
Mert ők is eltévednek a púderben. A honlapokat embereknek 
tervezték, akik a sok mellébeszélés között észreveszik a vil- 
logó szekszreklámot, és rákattintanak, mert tudják, hogy ott 
lesz valami csemege. A természetes intelligencia segít meg- 
fejteni a weboldalak tartalmát, és mi akkor is megtaláljuk a 
kívánt információt, ha átstrukturálják a lapot, ezzel szemben 
a szemétdombot túrogató programok sokszor eltévednek. 
Egy szónak is száz a vége: XML. Írjuk le a Webszolgánk által 
publikált szolgáltatásokat mindenféle felesleges körítés nél- 
kül oly módon, hogy azt a fogyasztó programok is könnyedén, 
szisztematikusan tudják értelmezni. Nem emberek, progra- 
mok. Az embereknek keretek kellenek, meg színes képek, de 
higgyék el, egy programot nem fogja lenyűgözni a Pléhboy 
(ismerjük, az Ózból) címlapja. Ha egy olyan programot szeret- 
nénk írni, amely csinos lányok képeit jeleníti meg a desktop- 
on a fenti lap képarchívumából, akkor az a program sokkal 
jobban örül egy, a képet reprezentáló bájtfolyamnak, mint 
egy csinos HTML lapnak (kinek a pap, kinek a paplan...) 

A lényeg, hogy a gépek számára írt szolgáltatásokat más 
módon gondolkodva kell megközelíteni. Nem honlapokban, 
hanem metódusokban, nem linkekben és tartalomjegyzé- 
kekben, hanem interfészekben, szolgáltatásokban és vég- 
pontokban kell gondolkodnunk. 

A mai világban a rövid fejlesztési időknek köszönhetően nem 
fogunk nekiállni írni például egy JPeg -: BMP kódolót, mert 
annyi ideig tartana, mint az egész projekt ideje. Nem írjuk 
meg, mert veszünk egy komponenst, amiben sok programo- 
zó nagyon sok munkával jól megírta azt, amit mi csak fárad- 
ságos munkával vagy sehogy nem tudtunk volna megtenni. 
Persze, pénzbe kerül, de például egy 1000$-os komponens (- 
300e Ft) árán maximum 3 napig lehet foglalkoztatni egy ko- 
moly fejlesztőt. Ennyi idő alatt eljut a diszkrét szinusz 
transzformáció megírásáig (rosszabb esetben még meg sem 
értette :). De a JPeg kódolás még egy kicsit odébb van... 

A Webszolgák világában szintén szolgáltatásokat veszünk, 
éppúgy, mint például egy COM komponens esetén. Csak míg 
az utóbbi esetben egy halott dolgot veszünk, aminek a va- 
ló világról az az utolsó lenyomata, hogy kirángatták a prog- 
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ramozó körmei közül. Ezzel szemben a Webszolgák mögött 
állhatnak élő, pillanatról-pillanatra változó adatbázisok, 
mérési eredmények, valódi, élő adatok. Minden egyes újabb 
hívás más és más információkat adhat vissza. Azért ez egy 
picit több, mint egy COM, CORBA, ... komponens, nem? 


A Webszolga technológia a Microsofté? 

Nem. Meg az XML sem. Sokszor tesznek fel hasonló kérdése- 
ket a hallgatók az XML tanfolyamokon. Az XML-ben benne van 
a Microsoft keze. Miben nincs? Ennek ellenére nem kisajáti- 
totta azt, hanem más cégekkel együttműködve megpróbáltak 
megegyezni egy egységes szabványhalmazban. A megegyezé- 
si folyamatot a World Wide Web konzorcium vezényli le, ahol 
leül a sok haragos ember, mindenféle cégek képviselői és ma- 
gánemberek, és megpróbálják kifürkészni a Világméretű Pók- 
háló jövőbeli alakulását. Pontosabban ők a pókok, akik szö- 
vögetik a hálót, mindig újabb és újabb hálókat szőve. 

Amint változik a világ igénye, úgy újabb és újabb protokol- 
tokkal, szabványokkal igyekeznek megtámogatni az elektro- 
nikus társadalmat. Újító lépés volt a HTTP protokoll kifej- 
lesztése a 90-es évek elején. Azóta is jól állja a sarat, egy- 
egy alkalmazás (SOAP, WebDAV) még további sok évre biz- 
tosítja a fennmaradását. 

A Webszolgák esetén egyértelműen ott áll a háttérben a Mic- 
rosoft. Ám (a Microsoft is változik) a Webszolga technológia 
nem egy zárt, céges szabvány, mint a COM vagy a JAVA 
nyelv. A specifikáció nem írja elő, hogy a háttérben Windows 
2000 Servernek kell állni, sőt, egyre több Webszolga megva- 
lósítás létezik például Linux és Apache alá. Bili bá nagy üz- 
letet lát benne, ezért sok fejlesztő dolgozik azon 
Redmondban, hogy Microsoft.NET alatt minél egyszerűbben 
lehessen Webszolgákat fejleszteni. De ez nem azt jelenti, 
hogy a .NET lesz az egyetlen platform a Webszolga fejleszté- 
sekhez, azonban fel kell kötni a gatyát a konkurenciának... 


A gépek és a politika birodalma 

Némi filozofálgatás után tekintsük meg a Webszolgák tech- 
nikai oldalát, és ismerkedjünk meg a főszereplőkkel! 
Gondolkodjunk el, milyen követelményeknek kell eleget 
tenni egy Webszolgákat támogató infrastruktúrának. 
Legalacsonyabb szinten kell egy olyan protokoll, ami támo- 
gatja a kérés-válasz alapú üzenetközvetítést. Erre tökéletes 
a HTTP, az okokról már korábban beszéltem. 

Jó lenne erre egy olyan réteg, ami az üzenetközvetítőt 
meglovagolva képes távoli eljáráshívásokat támogatni, 
elintézve a paraméterek kódolását és hívások logikáját. Er- 
re lett kitalálva új-régi ismerősünk, a SOAP. 

A SOAP hívások előkészítéséhez szükség van egy olyan for- 
mális leírásra, ami leírja egy Webszolga által nyújtott szolgál- 
tatásokat, azaz a rajta található metódusokat, azok paramé- 
tereit és visszatérési értékét. Ez kell a szolgáltatást igénybe 
venni kívánó fejlesztőknek, a fejlesztői környezeteknek. Le- 
hetne word doksi, de mint mondtam, a Webszolga nem MS 
technológia. Valamilyen gyártófüggetlen megoldás kellene, 
amelyet könnyen értelmeznek a számítógépek, de a humá- 
numnak sem törik bele a bicskája. Mi szólnának az XML-hez? 
A formális szolgáltatásleírást Web Services Description 
Language-dzsel (WSDL) valósítjuk meg. Ez egy XML fájl, ami 
pontosan definiálja a Webszolgán meghívható metódusokat 
és azok szerkezetét. 
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Egy kiszolgáló sokféle Webszolgát tartalmazhat, ezek leírá- 
sára létrehozhatunk egyfajta tartalomjegyzéket, amelyet 
Discovery információnak hívunk. Például a szolgáltató gyö- 
kerébe rögtön felveszünk egy ilyen Discovery fájlt, ami leír- 
ja az összes általunk nyújtott Webszolgát. 

Honnan tudom, hogy hol találok például egy időjárásjelen- 
tést szolgáltató Webszolgát? Cipészt vagy hastáncost a 
szakmai telefonkönyvekben keresünk. Kellene valami ha- 
sonló a Webszolgákhoz is. A Microsoft javaslata az elektro- 
nikus telefonkönyvre a UDDI szolgáltatás (Universal 
Description, Discovery, and Integration). Ez nem más, mint 
egy nagy kereső, amiben WSDL fájlok laknak, és a szolgál- 
tatást nyújtó cég mindegyikhez kitölti a potenciális ügyfe- 
lek számára fontos és érdekes információkat: az én 
Webszolgám ingyen kiszámítja a Nap és a Hold pillanatnyi 
távolságát. Az enyém hívásonként 1000 Ft-ért nem csinál 
semmit, de szeretnék gazdag lenni, ezért hívja meg min- 
denki, és adja meg a hitelkártya számát. Ezekből a plusz in- 
formációkból megkeressük a számunkra szimpatikus szol- 
gáltatást, és a visszakapott WSDL fájl alapján készen állunk 
arra, hogy nekilássunk azok használatához. 

A WSDL még csak egy Note, azaz feljegyzés a World Wide Web 
konzorciumnál. Sajnos a gyártók nehezen akarnak megegyezni 
közös formátumban, egyik sem akar engedni. De előbb utóbb 
lesz egy közös WSDL nyelv. Addig is a fogyasztó alkalmazások- 
nak (tipikusan fejlesztőeszközök) fel kell készülni a lehető leg- 
több WSDL nyelvjárás fogadására. De ez nem a mi gondunk. 
A UDDI kérdés még nehezebb. A világ soha nem bízott meg 
a Microsoftban. Én egyik cégben sem bízom meg. Az UDDI 
indítvány - , Webszolga telefonkönyv" mögött az MS áll. En- 
gem nem érdekel, hogy az MS mit csinál az általam publi- 
kált információkkal, hisz azokat azért teszem közzé, azért 
regisztrálom be hozzájuk, hogy minél többen láthassák, és 
így minél többen megvegyék a Webszolgámat. Valamilyen 
központi adatbázisra szükségünk lesz, amely nyilván elosz- 
tott lesz, és több cég kezében lesz. Hogy kinek a megoldá- 
sa fog győzni? Ez a jövő zenéje. 


Egy működő Webszolga 

.NET-ben Webszolgát írni majdnem annyira egyszerű, mint 
egy közönséges osztályt fabrikálni. Vegyük az alábbi egy- 
szerű osztályt: 


using System; 


public class MathService 

( 
public float Add(float a, float b) 
( 


return a t b; 


Ez egy CH nyelven leírt osztály, melynek neve MathService, és 
egy metódusa van, Add, mely két float típusú szám összegét ké- 
pezi. Ezt az osztályt már le lehet fordítani DLL-lé, és az így ka- 
pott ún. assembly-t már fel lehet használni más programokban. 
Lokálisan. Ott tartunk, ahol a COM tartott (nem DCOM, COM). 
Publikáljuk ezt ki a nagyvilágnak, mint egy Webszolgát! Mi 
sem egyszerűbb: 
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using System; 


using System.Web.Services; 


public class MathService : WebService 
( 

(WebMethod] 

public float Add(float a, float b) 

€ 

return a t b; 

, 

, 


A dőlt betűvel jelölt részek a kiegészítések. A MathService 
osztályunkat a WebService nevű osztályból származtattuk 
örökléssel. Ezt jelzi a : a két osztálynév között. Ez azt je- 
lenti, hogy az osztályunk tudni fog minden olyan szolgál- 
tatást, amit a WebService osztály is tud. Persze, hogy ott 
van megírva az összes implementációs részlet. Az említett 
osztály a System.Web.Services névtérben található, ezért 
használtam a using System.Web.Services; sort. E nélkül is 
működne az alkalmazásunk, csak akkor mindig ki kellene 
írni a teljes nevet, ami kényelmetlen lenne: 


public class MathService : 


System.Web.Services.WebService 


A Webszolgaként is hívható metódusainkat meg kell jelöl- 
nünk a [WebMethodj] attribútummal. Alapban nem lesznek 
a metódusaink publikálva, hisz sokszor rengeteg metódust 
használunk egy osztályban, de csak néhányat szeretnénk a 
nyilvánosság rendelkezésére bocsátani. 

Már csak kellene valaki, aki éjjel-nappal figyel, és várja, 
hogy valaki meghívja az Add metódusunkat. Ilyen feladatra 
kiváló egy webkiszolgáló, kivált, hogy a szervizünket HTTP 
protokollon szeretnénk elérni. Azért, hogy a webkiszolgáló 
tudja, hogy az előbb összeállított osztályt Webszolgaként 
akarjuk üzemeltetni, rakjuk azt bele egy .asmx kiterjesztésű 
állományba, és írjuk az elejébe az alábbi fejlécet: 


c30 WebService Language-"Cf" 
Classz"MathService" 35 
//Innen jön az előbbi osztály definíciója. 


using System; 


Már csak egy lépés van hátra: másoljuk fel az asmx fájlun- 
kat egy olyan IIS5 webkönyvtárba, amit mások is elérhet- 
nek, és amire fel van telepítve a .NET Framework futtató 
környezet (egy 18 MByte-os .exe a telepítő) . 
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[dos [Emez seo a I 
MathService 








The following operations are supported. For a formal definition, please 
review the Service Description. 


For more details on XML namespaces, see the W3C recommendation on 
Namespaces in XML. 


For more details on WSDL, see the WSDL Specification. 
For more details on URIs, see REC 2396. 


[ől 25 ET ars a 


B local intranet é 


0 Egy Webszolga alapértelmezett arca 


Nálam az xml7 virtuális könyvtár mögött található meg a 
Webszolga. Nézzünk rá böngészővel, mintha egy honlap lenne: 
A képről kivágtam a blablát, csak a lényeg van rajta. Az el- 
ső link a szervizünk formális WSDL leírására navigál el, 
mindjárt megnézzük közelebbről. Alatta pöttyel megjelölve 
van kilistázva egyetlen metódusunk. Ha lenne több, akkor 
mind itt lennének felsorolva. Alul láthatóak linkek a World 
Wide Web konzorcium honlapjára, a különböző felhasznált 
technológiákra. Hangsúlyozom, hogy a linkek nem a Micro- 
soft címére mutatnak, hanem a w3c honlapjára. 

Lássuk, mi tárul fel az első link (Service Description) mögött! 
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c?xmi versionz"1.0" encodingz"utf-g" ?5 2] 
"http:ZZu org/2001/XMLSchema" 
tp://schemas.xmisoap.orgzvisdi/http/" 
as.xmisoap.org/vesdl/mime/" 


















as.xmisoap.orgZvesi 
p://schemas .xmisoap.org/soap 
ttp:Z/tempuri.org/" 
cez"http://tempuri.org/" 
"http://schemas..xmisoap.org/visdi/"5 


attributeFormDefault-"gualified" 







- as:complexTypa 
- es:segyence: 
cs:element zta" maxOccursztit 
nameztő" type: loat" /2 
cs:element minOccursz"1" maxOccursztit az] 


a Hé tczd intranet 








a A WSDL fájl tartalma 


Egy WSDL dokumentumot kapunk vissza, amely a 
Webszolga URL-ünk WSDL paraméterezésével generálódott. 
Honnan ez a szép leírás? Nos, az ASP.NET futtató fogja a 
publikált osztályunkat, és az ún. Reflection képességek fel- 
használásával felderíti annak szerkezetét. Hasonló ez ah- 
hoz, ahogy egy program fel tudja deríteni egy COM Type 
Library-ből a COM komponens szerkezetét, csak .NET-ben 
sokkal részletesebb leírás készül a típusokról. A felderített 
szerkezetből pedig generál egy WSDL fájlt, ahogy az a fen- 
ti képen is látszik. A .NET rengeteg helyen kihasználja a 
gazdag típusleírásból fakadó Reflection lehetőségeket, egy 
nagycsomó kézi faragástól kímélve meg minket. 
Ragadjunk ki egy részletet a leírásból: 
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c?xml version-"1.0" encoding-"utf-8" ?5 

Sdefinitions 

xmlns:s-"http://www.w3.org/2001/XMLSchema" 

xmlns : soap-"http: //schemas . xmlsoap. org/wsd1/soap" 
vk 

Stypes2 


"£s:schema ... 


£s:element name-"Add"5 
£s:complexType? 
£s:seguences 
element minOccursz"1" maxOccursz"1" 
1 


maxOccursz"1 


s: 
namez"a" typez"s:float" 

:element minOccursz"1" tl 

name-"b" type-"s:float" /5 
£/s:seguence2 

£/s:complexType? 


£/s:element5 


€s:element name-z"AddResponse"5 
£s:complexType? 
€s:seguences 
€s:element minOccurs-z"1" maxOccursz"1" 
namez"AddResult" typez"s:float" /5 
£/s:seguence2 
£/s:complexType? 


£/s:element2 


£/s:schemaz 


£/types2z 


Látható, hogy a szolgáltatás hívását az Add nevű XML elem 
írja le, látható a két összeadandó paraméter is, amelyek tí- 
pusa float. Szemfülesebbek észrevehetik, hogy ez az XML 
darabka nem más, mint egy XML Schema dokumentum. 
Miért találjanak fel valamit, ami már ki van találva? Az 
AddResponse a hívásra adott választ formalizálja, amiben 
csak egy float visszatérési érték utazik. 


A másik oldal 

Kétféleképpen is munkára bírhatjuk Webszolgánkat. A leíró la- 
pon (kettővel ezelőtti kép) az Add linkre kattintva kapunk egy 
tesztlapot, amely segítségével tesztelhetjük a metódusainkat. 





a JD)2d 





[A mathService Web Service - MicrüsöfEíntSI 
Í Elie Edt Wew  Favorites Iools Help 
9 A 4! [Epersonalsar 


deBack 7 e 


Aseach (ájFavortes YID-Gá " 
zén 





Address E] http://focalhostfami7fmathserv.asmopmadd 





MathService 


Click 





for a complete list of operations. 














Add 

Test 
To test, click the "Invoke" button. 
Parameter Value 
a: 5 


b: [6 





Invoke 








HE Local intranet 





5 Még ki is próbálhatjuk a Webszolgát programozás nélkül! 
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Beírjuk az összeadandó paramétereket, és az Invoke gomb 
megnyomására meghívódik a szolga Add metódusa. 
Mit kapunk válaszul? Természetesen XML tartalmat: 


















zol x] 

Ele Edt Wiew  Favorítes  Iools Help 

egyn 0" encodingz"utf-8" ?a ká 

cfloat p://tempuri.org/"211c/float: HT 
€)0Done EE Localintranet 





5--6-11. Remek. A válasz névterét természetesen be lehet 
állítani a szervizben, mi most az alapértelmezett 
tempuri.org-ot használjuk. 

Hogyan utaztak a paraméterek a szolgához? Látható, hogy a 
metódus neve után ott van a két összeadandó hagyományos 
URL kódolással. Mivel a paraméterek az URL-ben utaznak, rájö- 
hetünk, hogy a háttérben egy HTTP GET metódushívás történt. 
Hol itt a SOAP? Sehol. Bár meg lehet hívni így is Webszolgákat, 
nem ez az ajánlott módszer. Hogyan fogunk lekódolni például 
egy tömböt vagy egy összetett objektumot? Legyen ez a S0AP 
gondja. Igen ám, de kellene egy olyan osztály vagy kompo- 
nens, amely képes olyan SOAP csomag összeállítására, amelyet 
a Webszolgánk közvetlenül képes fogyasztani. 

A .NET keretrendszer számtalan SOAP-hoz kapcsolódó osz- 
tályt bocsát a rendelkezésünkre. A 


System.Web.Services.Protocols. 


4 SoapHttpClientProtocol 


például szinte mindent elintéz helyettünk, ha egy 
Webszolgát szeretnénk használni SOAP-on keresztül. Ne- 
kiállhatunk kézzel is az osztály használatának, azonban ez 
nem lenne túl produktív. 


Jöjjenek a sémafordítók (schema compiler)! 

A WSDL precíz leírást ad a Webszolgán elérhető metódusokról. 
A SOAP egyértelmű kódolási szabályokat ad a paraméterek 
XML-lé alakítására. A SoapHttpClientProtocol osztály képes 
SOAP csomagok előállítására, és a Webszolga által visszakül- 
dött SOAP csomag értelmezésére. Ezek után már csak elő kell 
állítani egy olyan osztályt, ami a SoapHttpClientProtocol-ból 
származik örökléssel, és a segítségével egyszerűen meg lehet 
hívni Webszolgákat, egyszerűen úgy, mintha azok a saját gé- 
pen lakó objektumok lennének. Az ilyen átjátszó objektumo- 
kat általában Proxynak hívják. 

Azaz egy olyan megoldás a célunk, ahol nem SOAP csomago- 
kat dobálunk, hanem létrehozunk egy objektumot az ügyfél- 
alkalmazásban, és annak a metódusait meghívva a funkcio- 
nalitás nem a saját gépünkön fut le, hanem egy másik gép 
Webszolgájában. Ehhez kellene egy olyan eljárás vagy prog- 
ram, ami a WSDL leírás alapján automatikusan legenerál egy 
SoapHttpClientProtocol-ra épülő proxyosztályt. Másképpen 
fogalmazva egy olyan program, ami átjárást biztosít a WSDL- 
ben található XML Schema és a programozott objektumok vi- 
lága között. Ezeket a szoftvereket hívjuk sémafordítóknak. 
A .NET keretrendszerrel kapunk egy WSDL.EXE-t, ami ponto- 
san egy ilyen sémafordító. Paraméterül megadunk neki egy 
elérési utat (lehet fájlelérési út és URL is), ahol egy WSDL 
dokumentum található, és megadunk egy célnyelvet, amily 
nyelven fog létrejönni a proxyosztály. Generáljunk mondjuk 
egy CH nyelvű proxyt az előbbi Webszolgánk leírásából: 
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wsdl /language:ct 
4  http://localhost/xml7/mathserv.asmx?WSDL 


Kimenetként kapunk egy MathService.cs Ct állományt, 
Webszolgánk proxyosztályának forráskódját. 
Kukkantsunk bele: 
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// This source code was auto-generated by wsdl, 
// Version-1.0.2914.16. 

et 


public class MathService : 
4  System.Web.Services.Protocols. 
1  SoapHttpClientProtocol ( 
public System.Single 
Add(System.Single a, System.Single b) ( 
object[] results - 
this.Invoke("Add", new object[] (a, b)); 
return ((System.Single)(results[(0])); 


Látható, hogy a proxynak van Add metódusa, éppúgy, mint 
a Webszolgánknak, ráadásul pontosan olyan szerkezetben, 
mint ahogyan azt létrehoztuk. Azaz vár két lebegőpontos 
paramétert, és visszaad egy lebegőpontos eredményt. 

Ez a metódus a Webszolga szinkron hívására való. Ez azt je- 
lenti, hogy az Add metódus meghívása után addig nem kap- 
juk vissza a vezérlést, amíg az meg nem hívta a Webszolgát, 
és vissza nem kapta a választ. Mivel hálózatos és különösen 
internetes környezetben gyakori a több másodperces késlel- 
tetés, a szinkron hívások sokszor másodpercekre lefagyaszta- 
nák a felhasználói felületet, és az alkalmazásunkat (joggal) 
utálnák a felhasználók. A probléma kivédésére a proxy-ban 
megvannak az aszinkron híváshoz szükséges metódusok is. 
Ez azt jelenti, hogy kapunk egy BeginAdd nevű metódust is, 
amelynek paraméterezése hasonló az Add-éhoz, csak van neki 
néhány egyéb paramétere is. Többek között megadhatunk egy 
objektumot plusz paraméterként, amelynek egyik metódusát 
visszahívja a keretrendszer, ha az aszinkron hívás eredménye 
megérkezett. Azaz egyszerűen meghívjuk a BeginAdd-ot, átad- 
juk neki az összeadandó paramétereket, és megadunk egy sa- 
ját visszahívandó osztályt. A BeginAdd azonnal visszatér, de a 
háttérben (egy másik szálon) elindítja a Webszolga kommuni- 
kációt. Amikor az eredmények megérkeznek, meghívódik a 
visszahívandó osztályunk egy metódusa, és mi ebben például 
kiíratjuk az eredményt a felhasználónak. Ez a megoldás nyil- 
ván desktop ügyfélalkalmazásoknak jó, egy webalkalmazás 
nem nagyon tud profitálni az aszinkron lehetőségekből. 

Az aszinkron hívások témaköre nagyon jól ki van dolgozva 
a .NET-ben, meg fog érni egy teljes cikket a tárgyalása. 


Egyszerű ügyfélalkalmazás 

Ezek után írjunk egy konzolalapú ügyfélalkalmazást, ami a 
generált  proxyosztályon keresztül hívja meg a 
Webszolgánkat. A program nagyon egyszerű lesz. Létre kell 
hozni a proxyobjektumból egy példányt, és meg kell hívni 
az Add metódusát: 
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using System; 


class WebszolgaTeszt 
í 
public static void Main() 
í 
MathService m - new MathService(); 
float r - m.Add(5, 6); 


Console.WriteLine(r); 


Ahhoz, hogy a hivatkozott MathService osztályt tudjuk 
használni, a WSDL.EXE által generált proxy osztályt le kell 
fordítanunk egy DLL assembly-vé (mert abban van a 
MathService implementálva): 


csc /target:library MathService.cs 


Most, hogy megvan a proxy DLL, már csak a saját ügyfél- 
alkalmazásunkat kell lefordítatni: 


cse test.cs /r:mathservice.dll 
A /r kapcsolóból tudja a fordító, hogy a MathService osz- 


tály a mathservice.dll-ben található. 
Fordítás után miénk a test.exe, már csak futtatnunk kell: 





HTGCSZEETETISETSETTTTT T 2lDl2 


. ly Docunentstárt ielestXHloxni7ötert.exe 


er. 
1. 
C-X...Oytiy Docunentstárt feles tti? 


Ott a válasz, 11, amit már a Webszolgánk hívásával számol- 
tattunk ki. Ilyen pofonegyszerű használni az új Webszolga 
technológiát! 

Ezt a példát és egy jóval összetettebbet is kipróbálhat és 
letölthet a kedves olvasó, ha ellátogat a [1] címre. 


Zárszó 

Ha már a nyakunkon a .NET, a következő számban a .NET 
XML lehetőségeivel fogunk foglalkozni, amelyek megisme- 
rése sokkal közelebb fog vinni bennünket a Webszolgák lel- 
kivilágának megismeréséhez is. Amennyiben sikerült meg- 
zanak megírni nekem, milyen Webszolgákat látnának szíve- 
sen a NetAcademia webszerverén. A népszerű vagy prakti- 
kus ötleteket megvalósítom, és forrásukkal együtt kirakom 
a webünkre. Kíváncsian várom a javaslatokat! 


Soczó Zsolt 
Zsolt.Soczo (onetacademia.net 
A cikkben szereplő URL-ek: 
[1]: Letölthető kódok 
http://technet.netacademia.net/download/xml 
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Az ,e" előtaggal ellátott műszaki megoldások (például e- 
mail, e-commerce, e-cash stb.) közül egyesek gyakorlatilag 
teljesen, mások pedig egyre inkább elképzelhetetlenek a 
kriptográfia nélkül - részben a felhasználók személyes ér- 
deke, részben pedig a szabályozás terjeszkedése miatt. A 
bankszámlaszámok, PIN kódok, jelszavak, fontos üzenetek 
titokban tartása nem igényel különösebb magyarázatot. A 
tipikus felhasználó azonban egy tekintetben megváltoztat- 
hatatlan: nem komálja a macerát. Ahhoz, hogy a kriptográ- 
fia eredményeit használja is, lehetőleg ne kelljen a megszo- 
kottnál többet kattintania. Hát nem? Hát de! 

A kriptográfia alapja az algebra és az aritmetika. Az RSA 
(Rivest-Shamir-Adleman) algoritmus például két nagyon 
nagy prímszám szorzatán alapul: n-peg. (Ennél azért slight- 
ly bonyolultabb... Majd decemberben megírom - a szerk.) 

A Microsoft kutatói (saját bevallásuk szerint) naponta imád- 
koznak egy valódi egyirányú függvény létezésének bebizo- 
nyosodásáért. Ez érthető is: ha fellebbentik a fátylat a fak- 
torizálás rejtélyéről, akkor a kriptográfiának, és ezzel együtt 
az összes, ezen alapuló üzletágnak befellegzett. Magától ér- 
tetődően nem csak imádkoznak, hanem javítani próbálják a 
kódolás, a dekódolás és a titkosítókulcs előállításának se- 
bességét, hatékonyságát és biztonságát. Ha megtalálják a 
titok nyitját - legyen ez köszönhető akár a Mindenhatónak, 
akár a logikának, - a kriptográfia nagy mérföldkőhöz, ha 
nem egyenesen a végállomásához érkezik. 

Az elméleti kriptográfia célja az, hogy az X-en végrehajtott ma- 
tematikai műveletek segítségével előállított Y-ból X-et ne lehes- 
sen egyértelműen, pontosabban egyáltalán ne lehessen megha- 
tározni. Venkatesan kutató szerint a kriptográfia olyan rejtvé- 
nyek előállítása, amelyeket legalább az elkövetkező 20 évben 
nem fognak megoldani. Eddigi tapasztalatai alapján szkeptikus a 
végső megoldást illetően. Szerinte az egyirányúnak hitt algorit- 
musokról előbb vagy utóbb mindig kiderül az ellenkezője. Ettől 
való félelmében, Montgomery (az osztást szorzásokkal helyettesí- 
tő, róla elnevezett algoritmus feltalálója) a faktorizálás, mint fő 
veszélyforrás, különféle módszereivel próbálkozik. Egy 155 jegyű 
számot nemrégiben mindössze négy hónap alatt sikerült össze- 
tevőkre bontaniuk egy szobáravaló számítógéppel. A processzo- 
rok sebessége jelenleg olyan ütemben nő, hogy a mindössze szó 
használata az előbbi mondatban teljes mértékben tudatos volt. 
A kísérlet rámutatott, hogy a 155 számjegynek megfelelő 512 bit 
már kevés. Jöhet az 1024 bit és a 310 számjegy, ami az elődjé- 
nél hozzávetőlegesen egymilliószor nehezebbé teszi a feltörését. 
A számítógépek teljesítményének prognosztizálható növeke- 
désén túl további veszélyek leselkednek ránk. Hadd említsek 
itt kettőt. A SETI-vel betört a köztudatba is az Interneten 
elosztott feladatvégrehajtás. Ez már olyan változatban is léte- 
zik, amikor a felhasználónak fogalma sincs arról, hogy segéd- 
kezet nyújt egy számításban. Hány szobáravaló gép dolgozik 
ilyenkor? Jó sok! A kriptológusok egy másik nagy félelme a 
kvantumszámítógép, amely forradalmasíthatja a számítástech- 
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nikát. A hagyományos gépek memóriája 0-k és 1-ek sorozata, 
továbbá a számoknak csak egy adott halmazán végezhetünk 
egyidejűleg műveleteket. A kvantumgépek memóriája ellenben 
egy kvantumállapot, amely több szám szuperpozíciójából jön 
létre. Képes párhuzamosan akár az összes számon matematikai 
műveleteket elvégezni, illetve a köztük lévő interferencia ré- 
vén újabb eredményeket szolgáltatni. Emiatt aztán egy hason- 
ló méretű, konvencionális felépítésű gépnél sokkal nagyobb 
számítási sebesség is elérhető. A megvalósítást célzó elképze- 
lésekben nincs hiány - más kérdés, hogy a gyakorlat hol is tart 
valójában, és hogyan reagál az iparág egy ilyen innováció 
megjelenésére (hadd passzoljam haza a labdát azzal, hogy dr. 
Watsonnak pár hónappal ezelőtt a Byte magazinban megjelent, 
burkolt célzásoktól sem mentes cikkére utaljak :-) . 

A kulcsok hosszának növelésével végülis a feltörés ideje 
könnyedén eljuttatható az irracionálitás határára, az online 
alkalmazások azonban ezt az idővonzat miatt egyáltalán nem 
tolerálják. Ön például mennyit lenne hajlandó egy internetes 
vásárlásnál arra várni, hogy a számlaszáma biztonságosan el- 
jusson az eladó kiszolgálójára? Én annál is kevesebbet! 

A modern számítógépek a nyilvános kulcsú titkosításoknál 
manapság használatos 128 jegyű számon a másodperc szá- 
zadrésze alatt elvégzik a szükséges műveleteket. Első ráné- 
zésre azt mondhatnánk, ez aztán a sebesség, de ha arra 
gondolunk, hogy mindez egy olyan kiszolgálón történik, 
amely percenként több ezer felhasználó kérését teljesíti, 
akkor az eredmény hirtelen más fényben tündököl. A gya- 
korlati kriptográfia célja ennek megfelelően a sebesség és 
a biztonság közötti, ésszerű kompromisszum megtalálása. 
Montgomery, Lauter és Venkatesan egy ígéretes megoldáson is 
dolgoznak. A módszer az elliptikus görbéken alapul, amelyek 
egyszerű, köbös függvények. § 
Az ábrán pl. az y? -— x3 - 3x 
- 5 elliptikus függvény lát- 
ható, koordinátarendszerben 
ábrázolva. Az a és b ponto- 
kat összekötve egyértelműen 
megkapjuk c-t, de csupán c- 
ből az a-ra és a b-re nem kö- 
vetkeztethetünk. A lehetsé- 
ges megoldások száma elmé- 
letileg végtelen, de a véges 
számábrázolás a megoldáshalmazt is korlátossá redukálja. Az 
ilyen egyenletek felhasználásával nyilvános kulcsú titkosítási 
rendszerek hozhatók létre. Ez a technika, ugyanakkora kulcsot 
feltételezve, biztonságosabb az RSA-nal és a Diffie-Hellman 
módszernél is, továbbá kevesebb időre van szükség a kódolás- 
hoz és a dekódoláshoz. De talán még ezeknél az eredmények- 
nél is fontosabb, hogy a jelenleg ismert algoritmusokkal még 
az RSA-nál is lassabban lehet feltörni. 

A jelek szerint van még remény! 
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MCP vízsga a csizmábi 1. S 


Szerezze meg Ön is a Microsoft termékspecialista (MCP). minősítést! A Amennyiben 2001. december 6-ig jelentkezik bárme- 
lyik Microsoft vizsgára hivatalos Prometric vizsgaközpontunkba a, akkor most. az MCP vizsgát 22.000 Ft helyett akciós, 5.000 
Ft-os áron veheti igénybe. (Az akció idején belül 884 jee égy darab kedvezményes árú vizsgát vehet igénybe.) 


ey pY 


) 


Tanuljon karosszékből Microsoft Press kiadván ok 
Minden tisztelt vásárlónknak, aki legkésőbb. 2001. fecember 1 17. úg hivatalos MicrosofPress szakkönyveket rendel, 


ajándékba adjuk a magyar nyelvű Windows V ga ése lépésrő lépésre c. Hiadványt. ( (Az akció a készlet erejéig tart) 
EZ 


Tanuljon jöv őre Is nálunk . érdemes! 


A SZÁMALK Továbbképzés a jö -évben is ! Fe rődatlan áron kínálja"  tanfol jamait-— Szerezzen eladható tudást! 
Kedvezményes konstrukciójú hivatalos "Microsoft Windows 2000 rehdszermérrök képzésünk 2002. január 28-tól veszi 
kezdetét. Ha még ebben az évben fegisztrálja magát hivatalos Microsoft terra valamelyikére, 5.000 Ft értékű 
Microsoft Press könyvvásárfási utalványt ájándékozunk Önnek. Új Ú 


V Tanfolyami ízelítőnk: " 


21592 Implemehting Windows 2000 Pfofessional and Setver január : 28 - február 1. 








2272 Implementing Microsoft Windows XP Professional január 28 - február 1. 
2072 Administering Microsoft SOL Server 2000 Databases február 25 - március 1 
1572 Implementing Microsoft Exchange Server 20007 ) február 14- 18. 

2159 Implementing Mierosoft ISA Server 2000 február 25-26. 

2373 Visual Basic.NET for Develőpers . február 18-22. 
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